Last Comment Bug 605919 - serving flawed CSS to Firefox 4, can't view site
: serving flawed CSS to Firefox 4, can't view site
Product: Tech Evangelism Graveyard
Classification: Graveyard
Component: English US (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal
: ---
Assigned To: english-us
: 605966 606951 (view as bug list)
Depends on:
Blocks: 114156
  Show dependency treegraph
Reported: 2010-10-20 11:56 PDT by Mike Beltzner [:beltzner, not reading bugmail]
Modified: 2015-04-19 23:39 PDT (History)
35 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description Mike Beltzner [:beltzner, not reading bugmail] 2010-10-20 11:56:44 PDT
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 and thus our users are unable to click the links.

Only happens to Firefox 4.
Comment 1 Mike Beltzner [:beltzner, not reading bugmail] 2010-10-20 11:57:21 PDT
I evangelized this way: :)
Comment 2 Boris Zbarsky [:bz] 2010-10-20 12:07:56 PDT
Short story is this.  Their fade is done like so:

    fade: function () {
        if (AC.Detector.isCSSAvailable("transition")) {
            var b = function (c) {
      "transitionEnd", a)
            var a = b.bindAsEventListener(this);
  "transitionEnd", a);
  "opacity: 0;")
        } else {
                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 3 Marco Bonardo [::mak] (Away 6-20 Aug) 2010-10-20 14:16:16 PDT
*** Bug 605966 has been marked as a duplicate of this bug. ***
Comment 4 Olli Pettay [:smaug] 2010-10-21 01:29:37 PDT
Does Webkit actually have webkitTransitionEnd event?
Comment 5 Olli Pettay [:smaug] 2010-10-21 01:30:48 PDT
Based on some blogs, it does have webkitTransitionEnd.
That is an ill-named vendor-prefixed event.
Comment 6 Jonas Sicking (:sicking) PTO Until July 5th 2010-10-21 01:46:29 PDT
I'm poking people at apple.
Comment 7 José Alejandro Carrillo Neira 2010-10-21 02:16:49 PDT
Oh, let me add that this bug also affects unstable (not Canary) Google Chrome.
Comment 8 alex_mayorga 2010-10-21 06:30:12 PDT
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 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 2010-10-21 10:02:41 PDT
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
Comment 10 Maciej Stachowiak 2010-10-21 10:08:52 PDT
For future reference, the best way to report issues with Apple's web site is to file a bug at <>, component 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] 2010-10-21 10:29:16 PDT
(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 <>, component 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 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) PTO Until July 5th 2010-10-21 10:54:42 PDT
I've filed a bug and Maciej is getting the right people to look at it. I couldn't find a product either, so working with him on figuring out if this is indeed the place to file the bug.
Comment 13 Maciej Stachowiak 2010-10-21 11:12:57 PDT
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 2010-10-21 21:42:36 PDT
As an FYI to users hit by this, you can work around Apple's CSS bug by navigating to

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] 2010-10-22 11:23:21 PDT
FYI for evangelism and what not:
Comment 16 Jim Jeffery not reading bug-mail 1/2/11 2010-10-25 06:51:39 PDT
*** Bug 606951 has been marked as a duplicate of this bug. ***
Comment 17 Mehdi Mulani [:mmm] (I don't check this) 2010-10-26 10:47:09 PDT
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) {
      "transitionEnd", a);
                b = function () {}
            var a = b.bindAsEventListener(this);
  "transitionEnd", a);
  "opacity: 0;");
            b.delay(this.options.duration + 0.01, {
        } else {
                duration: this.options.duration
Comment 18 Boris Zbarsky [:bz] 2010-10-26 10:57:55 PDT
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] 2010-10-26 10:59:29 PDT

Note You need to log in before you can comment on or make changes to this bug.