508484 - ukraine.usembassy.gov - Carrousel is not working at all

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Siarhei Vaurynovich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

The bug is 100% reproducible.

When the mouse pointer hovers over menu items (like "U.S. Embassy in Ukraine", "Consular Services", "Information Services", "Programs\Grants", "Help") - red menus should open, allowing navigation on the web-site, but they do not when using FireFox.

The same web-site works just fine with Opera 9.64.

Reproducible: Always

Steps to Reproduce:
1. Go to http://kiev.usembassy.gov/main_eng.html
2. Hover the mouse pointer over any web-site menu item, like "U.S. Embassy in Ukraine" or "Consular Services".
3. Red menus should open allowing navigation but they do not.
Actual Results:  
Nothing happens when the mouse pointer hovers over any web-site menu item, like "U.S. Embassy in Ukraine" or "Consular Services". Clicking on the menu items does not produce any effect either.

Expected Results:  
Red menus should open when the mouse pointer hovers over any web-site menu item, like "U.S. Embassy in Ukraine" or "Consular Services", allowing navigation on the web-site.

The web-site works fine with Opera 9.64 - use it to see the expected results.

The web-site works fine with Opera 9.64.

Comment 1

[Kevin Brosnan]

document.layers is Netescape v4 javascript that is not supported any more. Site needs to use document.getElementById( aId ); for Gecko based browsers.

Comment 2

[Karl Dubost💡 :karlcow]

Attachment: carrousel.png

File not found." for the given URL
If I go to the main site. Menus are fine.

OTOH there is a big issue with the current caroussel
See Screenshot.

Comment 3

[Karl Dubost💡 :karlcow]

The carroussel is working in Safari.

Comment 4

[Hallvord R. M. Steen [:hallvors]]

The page attempts to define functions outerHeight and outerWidth:

// Returns the outerHeight of a given item
var outerHeight = function(element) {
  outerWidthResult = element.height() + num(element,'borderTopWidth') + num(element, 'borderBottomWidth') + num(element, 'paddingTop') + num(element, 'paddingBottom') + num(element, ',marginTop') + num(element, 'marginBottom');
  return outerWidthResult;
}

// Returns the outerWidth of a given item
var outerWidth = function(element) {
  outerWidthResult = element.width() + num(element,'borderLeftWidth') + num(element, 'borderRightWidth') + num(element, 'paddingLeft') + num(element, 'paddingRight') + num(element, ',marginLeft') + num(element, 'marginRight');
  return outerWidthResult;
}

however, these are property names in Gecko - both on window and on all HTML elements. Trying to call outerHeight() from the carousel code fails because the element.outerHeight property is found, and it's not a function.

(It seems Gecko doesn't allow redefining window.outerHeight either, so even if element.outerHeight wasn't in scope, it would fail).

It would be good to rewrite the code to use a different function name (or to just read the outerHeight property directly if it exists).

(bz: needinfo you to ask if Gecko is correct when a "var outerHeight" statement isn't allowed to create a variable shadowing the window.outerHeight one. WebKit allows it, and doesn't have element.outerHeight at all - the combination of these two differences makes the page work there. IE11 is perfectly aligned with WebKit.)

Comment 5

[Boris Zbarsky [:bzbarsky]]

> these are property names in Gecko - both on window and on all HTML elements

Uh.. No, just on window.  Why do you think it's a property name on HTML elements?

> needinfo you to ask if Gecko is correct when a "var outerHeight" statement isn't allowed
> to create a variable shadowing the window.outerHeight one.

"correct" is a slippery term.

What the current combination of CSSOM and Web IDL says to do: the outerHeight property is on the window itself, not on the prototype, and is readonly.  This means it cannot be shadowed or set, but can be redefined via explicit defineProperty calls.

What Gecko is doing is that the property is on the window itself and is writable; the setter will change the window height if the caller is allowed to do that.  So the assignments above end up being ignored because the caller is not in fact allowed to change the window height.

What IE11 is doing is what Web IDL _used_ to say to do: the outerHeight property is on the prototype, and is readonly.  That means that setting it doesn't work, but it can be shadowed via var.

What Blink is doing is that the property is on the window itself and is readonly but replaceable.  That means the property cannot be shadowed, but assigning to it will blow away the old property and redefine it to the new value.

So the upshot is that we're not following the spec, but even if we were that wouldn't make this site work.

We could get the spec changed to match the Blink behavior by making this attribute (and some others, perhaps: outerWidth, innerHeight, innerWidth, screenX, screenY, loooking at Blink's IDL) replaceable.  Then we could align with the spec and the site would work.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Oh, and Safari does the same thing as Blink, for what it's worth.

Comment 7

[Hallvord R. M. Steen [:hallvors]]

(In reply to Boris Zbarsky [:bz] from comment #5)
> > these are property names in Gecko - both on window and on all HTML elements
> 
> Uh.. No, just on window.  Why do you think it's a property name on HTML
> elements?

Wot.. I swear I saw that during debugging :-o But you're right (of course), I don't see it now. Not even on that site..

> We could get the spec changed to match the Blink behavior by making this
> attribute (and some others, perhaps: outerWidth, innerHeight, innerWidth,
> screenX, screenY, loooking at Blink's IDL) replaceable.  Then we could align
> with the spec and the site would work.

From a "site compatibility concerns" perspective, that sounds good to me. (We tend to assume we're seeing the tip of an iceberg when we deal with a problem like this. If minimising compat risk doesn't cause bad complications in the code or mess with web developers head, I'm all for it).

Comment 8

[Boris Zbarsky [:bzbarsky]]

It would cause complications in _our_ code, given we want to preserve the ability for sufficiently empowered callers to set these values.  But not fatal complications.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

(Can't such scripts just use window.resizeBy() or window.resizeTo() ?)

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Can't such scripts just use window.resizeBy() or window.resizeTo()

It depends.  And updating extensions is always chancy....

Comment 11

[Hallvord R. M. Steen [:hallvors]]

Seems they fixed this, per automated and manual testing :)

Comment 12

[LoveHacker]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

like - https://htlmadras.com/backlink-kya-hai-kaise-banaye/
https://htlmadras.com/free-fire-redeem-code/