560505 - gray overlay blocks content after switching seats in extra legroom section on JetBlue seat reservation

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

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

This happens on Firefox 3.0.*, 3.5.* and 3.6.* which tells me it's probably tech evangelism, but it does work on Webkit based browsers so we might be doing something wrong. I've cc'd some DOM and Layout folks, doesn't appear to be JS.

STR:

1. Go to www.jetblue.com
2. Pick any two flights, any two days
3. Enter whatever contact information you want
4. Continue to seat selection (no payment needed)
5. Pick a seat in the extra legroom section
6. Confirm that you're OK with the extra cost
7. Pick any other seat in the extra legroom section

Expected: seat selection moves to the new seat selected in step 7
Actual: gray overlay appears and blocks all interaction with content

Once the web page gets into this state there's nothing you can do to get it out other than reload the page.

Comment 1

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

(originally reported by [e-mail] who asked me to file the bug on her behalf)

Comment 2

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

Roc: what's the additional QA wanted here?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

same as testcase-wanted, but I don't know which flags people actually watch

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: zip of seat selection page

Here's a ZIP file containing the seat selection page, saved with Save Page As...complete, and with the CSS urls fixed up.

I don't see the problem on:
 * the live page, mozilla-central, Linux
 * the zip file page, mozilla-central, Linux
 * the zip file page, Firefox 3.5, Linux

Is this Mac only?  Do you see the bug with the version of the page in this zip file on the Mac?

If so, it's a useful start for reducing the testcase...

Comment 5

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

Yup, can confirm that the ZIP file causes the issue as described in comment 0. Before we declare this as OSX-only, can we get someone (Gavin?) to try it on Windows for us?

Comment 6

[Timothy Nikkel (:tnikkel)]

Works correctly for me on Windows trunk.

Comment 7

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

That might explain why we haven't seen many reports of this - everyone knows OSX users are rich and don't need to fly JetBlue ;)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Or are poor and can't afford the extra legroom?  Or are short and don't care?  ;)

If I spoof a Windows user-agent string in my Mac build, the bug disappears.  It's present if I don't do said poofing.

Comment 9

[Boris Zbarsky [:bzbarsky]]

s/poofing/spoofing/

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does changing the assignment to s.ismac in s_code_remote.js also fix it?

Comment 11

[Boris Zbarsky [:bzbarsky]]

In container-min.js if I change the "mac" to "windows" in the relevant return codepath in "platform: function() ..." then the bug goes away.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Does changing the assignment to s.ismac in s_code_remote.js also fix it?

No.

containe-min (which is apparently Yahoo yiu version 2.7.0) has all sorts of crud that does special things for Gecko per-platform.  Ignoring the ones that have to do with something called macGeckoScrollbars, I see:

  var R = (I.gecko && this.platform == "windows");

(something runs async if R but sync if !R).  And:

  if (this.platform == "mac" && K.gecko) {

(some checks for !alreadySubscribed go in that block).  And:

   var b = (this.platform == "mac" && L.gecko),

(followed by |if (!b) Y.call(this)| in the "matte" case for configUnderlay).

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, but the one that causes this problem is in the configVisible function.  Specifically:

  U = (this.platform == "mac" && K.gecko),

and then in the |if (Q)| case:

  if (U) {
    this.hideMacGeckoScrollbars();
  }

If I make that test |U && 0| the bug goes away.

Comment 14

[Boris Zbarsky [:bzbarsky]]

That said, hideMacGeckoScrollbars is:

  hideMacGeckoScrollbars: function () {
    F.replaceClass(this.element, "show-scrollbars", "hide-scrollbars");
  },

and replaceClass seems to be:
  replaceClass: function (x, Y, G) {
      return E.Dom.batch(x, E.Dom._replaceClass, {
          from: Y,
          to: G
      });
  },
  _replaceClass: function (y, x) {
      var Y, AB, AA, G = false,
          z;
      if (y && x) {
              AB = x.from;
              AA = x.to;
              if (!AA) {
                  G = false;
              } else {
                  if (!AB) {
                      G = E.Dom._addClass(y, x.to);
                  } else {
                      if (AB !== AA) {
                          z = E.Dom.getAttribute(y, F) || J;
                          Y = (B + z.replace(E.Dom._getClassRegex(AB), B + AA)).split(E.Dom._getClassRegex(AA));
                          Y.splice(1, 0, B + AA);
                          E.Dom.setAttribute(y, F, A(Y.join(J)));
                          G = true;
                      }
                  }
              }
          } else {}
      return G;
  },

Nothing jumping out at me here as something that would break things.  There are no weird exceptions thrown (or rather the same set is thrown whether the page works or not).  Note that I'm including exceptions the page catches; anything that makes it to JS_SetPendingException.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I really want to say evang offhand, but I just don't see why this code should break things.  Do we have any yahoo contacts?

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FWIW, the comments in the YUI code say it's to work around bug 187435, which was fixed in Firefox 3.

The CSS for .hide-scrollbars is potentially pretty invasive:

.hide-scrollbars,
.hide-scrollbars * {

    overflow: hidden;

}

.hide-scrollbars select {
    display: none;
}

Comment 17

[Boris Zbarsky [:bzbarsky]]

What's odd to me is why it would only affect the _second_ click.  The same js seems to run on both clicks.

Comment 18

[Boris Zbarsky [:bzbarsky]]

The overflow:hidden rule (as expected) is the one that causes the problem.

The first time the dialog comes up the outer div (id="emlOverlay_c") has the classes "yui-panel-container yui-dialog show-scrollbars" and the <body> as the parent.

The _second_ time the dialog comes up, there are two divs with that id.  The inner one is as above.  But its parent has the same id, has the <body> as the parent, and has the classes "yui-panel-container yui-dialog hide-scrollbars yui-overlay-hidden".  So it gets the overflow:hidden styling.  The yui-panel-container class sets position:absolute.  Since both the inner and outer div have that class, the outer div has no in-flow kids, so ends up with width and height 0, and overflow:hidden.  So the inner div is not visible.

I checked a build with the UA spoofed to a Windows UA and the nested divs are present there too.  So that part is not Mac-specific.  In fact, every time I click on a seat one more div is added to the nesting, all with the same id.  At this point I'm quite happy to send this to evang.

Comment 19

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

Kev: do we know anyone on the YUI team who can help us with this? We might also want to let JetBlue know, but I bet they're just pulling in YUI.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Given the nesting level increase thing, they may well be misusing YUI...

Comment 21

[Karl Dubost💡 :karlcow]

Tested. And working for me.