605919 - apple.com serving flawed CSS to Firefox 4, can't view site

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

bz has more details, but basically because of poor assumptions about support for CSS transitions and use of webkit-only events, we're not getting a display:none rule applied to the big div that fades away on www.apple.com and thus our users are unable to click the links.

Only happens to Firefox 4.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

I evangelized this way: http://twitter.com/beltzner/status/27956020097 :)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Short story is this.  Their fade is done like so:

    fade: function () {
        if (AC.Detector.isCSSAvailable("transition")) {
            var b = function (c) {
                c.target.hide();
                c.target.removeVendorEventListener("transitionEnd", a)
            };
            var a = b.bindAsEventListener(this);
            this.bo.element.addVendorEventListener("transitionEnd", a);
            this.bo.element.setStyle("opacity: 0;")
        } else {
            this.bo.element.fade({
                duration: this.options.duration
            })
        }
    }

isCSSAvailable tests whether the property name is parsed, whether on its own or with the "-moz-" and "-o-" and "-webkit-" prefixes.  So it returns true in Gecko 2.0 and we take the if, not the else.

addVendorEventListener adds listeners for all sorts of variants of the first string.  In this case, for "transitionEnd", "webkitTransitionEnd", "mozTrasitionEnd", "oTransitionEnd", "msTransitionEnd".  The hide() call above is what needs to happen for the display:none to be set on the div for it not to block clicks.

All this is good, but the event name in the transitions spec is "transitionend" (note lowercase "E"), and we implement it unprefixed, with that name.  And event names are case-sensitive.  So this fails to actually remove the display:none when the transition completes.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Does Webkit actually have webkitTransitionEnd event?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Based on some blogs, it does have webkitTransitionEnd.
That is an ill-named vendor-prefixed event.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm poking people at apple.

Comment 7

[José Alejandro Carrillo Neira]

Oh, let me add that this bug also affects unstable (not Canary) Google Chrome.

Comment 8

[alex_mayorga]

This is platform "All".
After seeing people around the water cooler drool over some not new features "El Jobso" announced yesterday I went to check apple.com on Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020120347 but the links are not functional.

Comment 9

[Chad Weimer]

You can use user styles to inject "#ACBlackout { display: none; }" into the site to get it working again. Of course, what does anyone really need on apple.com?

Comment 10

[Maciej Stachowiak]

For future reference, the best way to report issues with Apple's web site is to file a bug at <http://bugreport.apple.com/>, component apple.com/New Bugs. I'm working with Jonas to get the issue reported and brought to the attention of the right people.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #10)
> For future reference, the best way to report issues with Apple's web site is to
> file a bug at <http://bugreport.apple.com/>, component apple.com/New Bugs. I'm
> working with Jonas to get the issue reported and brought to the attention of
> the right people.

Thanks - I tried that, there was no product for the apple.com websites and Radar issues go into a black hole that I can't see so there would have been no way for me to know if that was right. I'll know for next time. I'm assuming you've already filed a report there?

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I've filed a bug and Maciej is getting the right people to look at it. I couldn't find a apple.com product either, so working with him on figuring out if this is indeed the place to file the bug.

Comment 13

[Maciej Stachowiak]

I forgot that the public interface to Radar doesn't let you enter a component. But I'll make sure it gets routed properly.

Comment 14

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

As an FYI to users hit by this, you can work around Apple's CSS bug by navigating to http://www.apple.com/mac

From there you can hit the rest of Apple's site, including the home page via the Apple logo on the left of the top toolbar. The offending CSS transition won't appear when navigating from within Apple's site.

Comment 15

[Aakash Desai [:aakashd]]

FYI for evangelism and what not: http://input.mozilla.com/en-US/site/http/apple.com?search_type=latest+beta

Comment 17

[Mehdi Mulani [:mmm] (I don't check this)]

Appears to be fixed as of 2010-10-26. (today)

The corresponding fade code from comment 2 has been changed to:
    fade: function () {
        if (AC.Detector.isCSSAvailable("transition")) {
            var b = function (c) {
                c.target.hide();
                c.target.removeVendorEventListener("transitionEnd", a);
                b = function () {}
            };
            var a = b.bindAsEventListener(this);
            this.bo.element.addVendorEventListener("transitionEnd", a);
            this.bo.element.setStyle("opacity: 0;");
            b.delay(this.options.duration + 0.01, {
                target: this.bo.element
            })
        } else {
            this.bo.element.fade({
                duration: this.options.duration
            })
        }
    }

Comment 18

[Boris Zbarsky [:bzbarsky]]

That change is window dressing.  The important change is in addVendorEventListener, which now does this:


    addVendorEventListener: function (b, c, d, a) {
        if (typeof(addEventListener) == "function") {
            if (c.match(/^webkit/)) {
                c = c.replace(/^webkit/, "")
            } else {
                if (c.match(/^moz/)) {
                    c = c.replace(/^moz/, "")
                } else {
                    if (c.match(/^ms/)) {
                        c = c.replace(/^ms/, "")
                    } else {
                        if (c.match(/^o/)) {
                            c = c.replace(/^o/, "")
                        } else {
                            c = c.charAt(0).toUpperCase() + c.slice(1)
                        }
                    }
                }
            }
            b.addEventListener("webkit" + c, d, a);
            b.addEventListener("o" + c, d, a);
            b.addEventListener(c.toLowerCase(), d, a);
            c = c.charAt(0).toLowerCase() + c.slice(1);
            return b.addEventListener(c, d, a)
        }
    }

and the changed part there is the addition of this line:

            b.addEventListener(c.toLowerCase(), d, a);

and the removal of this line that used to be there:

            b.addEventListener("moz" + c, d, a);

That fixes things for the transitionend event, obviously; not sure whether there are any other relevant events, since we tend to prefix events with "Moz", not "moz".  This also means that gunk near the beginning that matches on /^moz/ is bogus too, but that doesn't matter in this case.

Beltzner, note that they're now adding a listener for "transitionend" _and_ "transitionEnd".  So if we made event names case-insensitive as you've proposed they'd get now two event listeners firing, not just one...

In any case, this is indeed fixed.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Hooray-ish.