views:

263

answers:

1

Hi,

I've been scratching my head for hours trying to figure this out. I have this page: http://173.203.72.190/default.aspx. On clicking 'Any Cuisine', a sort of overlay is supposed to open.

It works fine in nearly all browsers except IE6 and Opera. In IE6 and Opera, the jQuery 'overlay' won't open.

Anybody have any ideas why this might be?

Edit: The code triggering the overlay is below:

$("a#zoneListLink").click(function() { 

    var listTop = $(this).css("top");
    var listLeft = $(this).css("left");

    var api = $("a#zoneListLink").overlay({api: true, close:'div.close', top: listTop, left:listLeft, onLoad:function() { $(document).click(function() { api.close(); } ); },
    onClose:function() { $(document).unbind("click"); } }).load();

});
+1  A: 

There is a bug or incompatibility inside the jQuery overlay effect. It's hard to find because Opera's behaviour makes more sense, but breaks the script's buggy expectations..

First, compare the output of this command in Opera and for example Firefox:

javascript:alert(getComputedStyle(document.getElementById("cuisineListLink"),'').top);

Opera gives you the top position of the cuisineListLink in pixels. Firefox says "auto".

Now, in combined.js look for this code (wrapped by me):

if(typeof t=="string"){
    t=t=="center"?Math.max((n.height()-q)/2,0):parseInt(t,10)/100*n.height()
}

I have no idea why it does "parseInt(t,10)/100*n.height()", but it looks like this code expects either the string "center" (to do vertical centering of the layer) or a number. When Opera passes in a string like '310px', the script will extract the integer, divide it by 100 (i.e. 3.1) and multiply it with the height of your browser window (?!). Net effect is that the overlay is positioned carefully outside of the screen - 3 screen heights down.

In Firefox, we get to this line and the t variable is the string 'auto'. The script tries parseInt() which returns 'Not a Number', NaN, and proceeds to divide by 100 and multiply with window height - which of course keeps returning NaN. Then it positions the overlay at NaNpx which the browser will simply ignore as a bogus value. You will find a warning to that effect in Firefox's error console.

I'd recommend using a different overlay plugin (or perhaps a newer iteration?) because this code doesn't make much sense.

hallvors
Fantastic work! I must admit that my question was a bit like finding a needle in a haystack (without context, very difficult to debug), and you have nailed it!I found out last night that 'listTop' and 'listLeft' were returning 'auto'. I realized (correct me if I'm wrong), that this was because the overlay control created a control with position as 'static' on the window.
Wild Thing
I changed the code to the below: var listPosition = $(this).offset(); var api = $("a#zoneListLink").overlay({api: true, close:'div.close', top: listPosition.top + 26, left:listPosition.left, onLoad:function() { $(document).click(function() { api.close(); } ); }, onClose:function() { $(document).unbind("click"); } }).load(); made position absolute instead of static -> $("#zoneList").css("position", "absolute");and it works!
Wild Thing
Another way to solve it - if the markup is going to remain as it was - would be to just leave the overlays static and not pass in any values for top/left at all. After all, the overlays were perfectly positioned in other browsers where the script failed to reposition them :). So instead of listPosition.top+26 I guess you could pass null or something? Or just hard-code the string "auto". Consider it a performance optimisation - of course if the markup might be moved around you're better off keeping the current version.
hallvors
(BTW, I realised why the script is written that way: it supports percentages. So it expects either a number, the string "center" or a percentage inside a string like "25%". Its bug is to just check if the input is a string and not look for the actual '%' sign before doing the percentage calculations.)
hallvors