400082 - [10.5] Unable to access dropdown list on this site, works on Tiger

Status: VERIFIED FIXED

(Core Graveyard :: Widget: Mac, defect)

Description

[Marcia Knous [:marcia]]

Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8) Gecko/2007100816 Firefox/2.0.0.8.

STR:
1. Go to URL.
2. Click on the dropdown widget under the Featured Artists. Nothing happens.

This works fine using the same build on Tiger. No errors appear in the error console.

Comment 1

[Jamis Buck]

We are seeing the same behavior in Basecamp (http://www.basecamphq.com) on certain dropdowns (but not all). We're not sure yet what is causing it, but we'll post more when we have a reproducible test case.

Comment 2

[Sam Stephenson]

Attachment: Test case demonstrating broken behavior in OS X 10.5

I've pared down one of Basecamp's pages to produce a test case, using Firefox 2.0.0.8 and OS X 10.5.  400082.zip contains two files:

* broken.html demonstrates the problem we're seeing with certain select elements.  When you click the "Add an item" link on the page, the inline style property of the element with ID "list_1443274_new_item" is changed with JavaScript to "" (when the page loads, its HTML style attribute has the value "display: none").  This change displays a form on the page, with a select element following the text "Who's responsible?"  Clicking on the select element appears to give the element focus, but does not display the element's drop-down menu as expected.

* working.html is a copy of broken.html with the "list_1443274_new_item" element's inline style attribute removed, so the form and its select element are visible when the page loads.  Under these circumstances, the form's select element displays its drop-down menu when clicked.

Comment 3

[Sam Stephenson]

Here's a QuickTime video demonstrating the test case in attachment 286585 [details]:
http://s3.amazonaws.com/sstephenson/public/mozilla-400082.mov

Comment 4

[Marcia Knous [:marcia]]

I retested this with the released version of Leopard (Mac OS X 10.5 (9A581) and using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/2007102514 Firefox/2.0.0.9. I still see the issue on the foliolink site. Note that this is not an issue on the trunk running Leopard, the same dropdown that doesn't work on the branch works fine.

Comment 5

[Marcia Knous [:marcia]]

Forum topic with more info from users that have hit this bug: http://forums.mozillazine.org/viewtopic.php?t=597793

Comment 6

[Marcia Knous [:marcia]]

http://forums.mozillazine.org/viewtopic.php?t=597655 notes an issue on the travelocity site, which I can confirm is present on Leopard but not tiger, using Firefox 2.0.0.8.

Comment 7

[Jeremy Kitchen]

We've had several customers write in about this as well, and we've been able to reproduce it but only in very specific situations customers wouldn't be able to get into.  I can provide additional details if need be, but it seems we aren't alone, so I'll wait for more information!

Comment 8

[Wilson Rector]

The bug only happens with select elements generated by Javascript, such as one generated with an AJAX request.

This is obviously a huge problem on sites such as Kelly Blue Book (http://www.kbb.com), which use multi-level select elements that change based on the selected option in the previous select element. Try clicking 'Used Vehicles', and then fill out information about a vehicle. If you are using OS 10.5 and Firefox 2.0.0.8, they will not work.

Comment 9

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

This bug (which I can totally confirm, if Marcia and the excellent reports here weren't enough) totally hoses the experience on web-2.0-ajaxy websites :(

Nominating for 2009

Comment 10

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Did this ever work in FF2008?

Comment 11

[Samuel Sidler (old account; do not CC)]

I just tested this back to Firefox 2.0.0.2 (I can go back further if needed) and could reproduce it in all of those builds. This isn't something we regressed.

Comment 12

[Mike Schroepfer]

Any ideas for workarounds?

Comment 13

[Martijn Wargers (dead)]

When started it working on trunk?

Comment 14

[Steven Michaud [:smichaud] (Retired)]

I'm going to start trying to find a fix for this.  I hope to have
something more definite to say by sometime tomorrow.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> When started it working on trunk?

I'm going to try to find out.  But if someone else finds out first,
don't hesitate to comment :-)

Comment 16

[Samuel Sidler (old account; do not CC)]

This became fixed on trunk when Cocoa widgets landed on September 28, 2006.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #2)

Sam, I was hoping to use your testcase (and its detailed explanation)
to get some idea of what the problem is ... but your broken.html also
fails to work in Safari and recent Minefield trunk nightlies (which
don't have the problem reported in comment #0).

If possible, please revise your broken.html so that it fails in
Firefox 2.0.0.8 but works in Safari and Minefield.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

> If possible, please revise your broken.html so that it fails in
> Firefox 2.0.0.8 but works in Safari and Minefield.

Oops, I misunderstood your comment.

Your broken.html testcase works just as promised.

Sorry.

Comment 19

[Mike Schroepfer]

Steven - any updates?

Comment 20

[Marcia Knous [:marcia]]

adding jresig to the bug, as I saw he wrote some documentation on jquery, and that is something that is mentioned in the forum post noted in Comment 5.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

I've now been at it all day, and I've dug deep into content and layout
objects like nsHTMLSelectElement, nsComboBoxControlFrame and
nsListControlFrame ... but I still haven't found the place(s) where
the code paths differ between Tiger and Leopard.

This problem is definitely worth pursing further, and I'll continue to
do so (thanks to Sam Stephenson we've got a very good testcase).  But
it looks like it's going to take longer than I first thought to come
up with a fix (or at least a diagnosis).

Thankfully the Firefox 2.0.0.9 release is no longer being held up by
this bug, so the pace need no longer be so frantic.

Comment 22

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

Thanks for the update, Steven: does the minimal testcase give us a firm understanding of what combination of script/form elements cause the behaviour? I'd like to be able to announce the scope of the issue on DevNews and/or in dev.apps.firefox ...

Comment 23

[Steven Michaud [:smichaud] (Retired)]

I'm about to post a fix for this, and an explanation.

Can you hold on for about an hour? :-)

Comment 24

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

Here's a fix for this bug.

It needs more testing.  In particular I've only been able to test on
the last developer seed of Leopard (OS X 10.5) before the release
(build 9A559) -- not yet on the release version (build 9A581).  But
I'm reasonably confident this patch does fix the problem, even on the
release version.

When I started work on this, I was sure it'd turn out to be an Apple
bug -- after all it only happens on Leopard.  But it's not an Apple
bug.

In fact it's a Mozilla.org bug, which was uncovered by a very subtle
change in Leopard's behavior from previous OS X versions (e.g. Tiger
aka OS X 10.4.X).

I won't repeat what I said in my patch's comments.  Put most simply,
the bug is in code that tries to constrain a window's dimensions as
it's being created, and shows up when the window is created empty.
The reason it only happens on Leopard is that a system call
(GetWindowBounds()) behaves slighly differently on Leopard (compared
to previous OS X versions) when it's called on an empty window (one
with zero width and/or height).  But GetWindowsBounds()'s results
aren't "wrong", so this isn't an Apple bug.

Whoever's seen this problem, please test with a test build that I've
made available at the following URL.  Let us know your results ... but
don't crowd this bug with reports on different, unrelated bugs :-)

https://build.mozilla.org/tryserver-builds/2007-11-03_15:[e-mail]-bugzilla400082/[e-mail]

Comment 25

[Marcia Knous [:marcia]]

Steven: First, thanks for all your hard work on this bug. Using the build you note in Comment 24, I no longer see the dropdown issue on foliolink or travelocity. If I load Sam's test case in Comment 2 (broken.html), I do see the list of names under "Who's responsible."  I am testing with Mac OS X 10.5 (9A581), on an Intel MBP.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

> Steven: First, thanks for all your hard work on this bug.

You're most welcome, Marcia :-)

By the way, you might want to put my test build through whatever
automated tests you use on regular builds.  My patch makes changes to
code that's exercised whenever a window is created.

Comment 27

[neil epstein]

Steven - We were also experiencing this on gothamist.com (the view menu on the top middle right) and also in MovableType 3.34 - the entry filter screen. Both of these are menus loaded by Ajax calls. Your build did solve the issue for us in both cases.

Any idea what the time line will be for getting this in a released version? This is part of a new feature of our site, so we'd like to get it compatible for everyone as quickly as possible.

Thanks again!

Comment 28

[Steven Michaud [:smichaud] (Retired)]

> Your build did solve the issue for us in both cases.

Glad to hear it.

> Any idea what the time line will be for getting this in a released
> version?

My patch needs to be reviewed and superreviewed, and to be given at
least some additional testing (presumably by Marcia's QA folks).  I
don't expect this to take long.

But as for when it'll get into a release version ... that's not my
call.  Mike Belzner might have more to say on this subject.

> Thanks again!

You're most welcome.

Comment 29

[Josh Aas]

Comment on attachment 287254 [details] [diff] [review]
Fix

+    if (!aRect.IsEmpty()) {
+      // Getting kWindowContentRgn can give back bad values on Panther
+      // (fixed on Tiger), but wRect is already set to the content rect anyway.
+      Rect structure;
+      ::GetWindowBounds(mWindowPtr, kWindowStructureRgn, &structure);
+      mBoundsOffset.v = wRect.top - structure.top;
+      mBoundsOffset.h = wRect.left - structure.left;
+    } else {

Why not put the IsEmpty() == TRUE case first so we don't need the '!'?

Fix on checkin if you want, not a big deal.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

> Why not put the IsEmpty() == TRUE case first so we don't need the '!'?

No problem.  I'll do it when I land the patch.

Comment 31

[Mike Schroepfer]

(In reply to comment #27)

> Any idea what the time line will be for getting this in a released version?
> This is part of a new feature of our site, so we'd like to get it compatible
> for everyone as quickly as possible.

Neil - unfortunately this patch just missed the 2.0.0.9 release which went out last Thursday.  We'll likely get this out in a 2.0.0.10 release in Early December.

Comment 32

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 287254 [details] [diff] [review]
Fix

This patch has moderate risk but substantial benefits.

Moderate risk because I've changed code that's exercised whenever a
window is created.  A bit more testing should be all that's needed to
dispel any doubts about this.

Substantial benefits because this bug appears to effect a _lot_ of
websites -- particularly those that use advanced features like dynamic
reformatting or loading of content.

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 287254 [details] [diff] [review]
Fix

approved for 1.8.1.10, a=dveditz for release-drivers

Comment 34

[Steven Michaud [:smichaud] (Retired)]

Landed on the 1.8 branch with Josh's code change and some revisions to
the comments.

Comment 35

[Samuel Sidler (old account; do not CC)]

Adding fixed keyword.

Comment 36

[Marcia Knous [:marcia]]

verified fixed using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.10pre) Gecko/2007110806 BonEcho/2.0.0.10pre. I visited foliolink, http://travelocity.com/, and Kelley Blue Book.  All dropdowns work. I will check and Intel Mac as well just to be doubly sure.

Comment 40

[Rowan Beentje]

I ran into this bug on two work websites, on one of which the select menu was static and not generated via javascript. I can confirm that the bug is fixed with the 1.8 branch nightly, "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.10pre) Gecko/20071115 BonEcho/2.0.0.10pre".  Tested on OS X 10.5 on Intel.

Comment 41

[Marc Bejarano]

is this a problem on trunk, too?

Comment 42

[Marc Bejarano]

(In reply to comment #4)
> Note that this is not an issue on the trunk running Leopard, the same dropdown
> that doesn't work on the branch works fine.

oops.  sorry for the noise :(

Comment 44

[Jake Olefsky]

I know that this is fixed and ready for the next release, but I just wanted to point out that this affects Gmail. With Firefox on Leopard, you can no longer select an alternate "From" address when composing an email in Gmail.

Comment 45

[Samuel Sidler (old account; do not CC)]

Would be good to get this in a test suite (Litmus or otherwise) to make sure it doesn't break again. (I know it hasn't been broken on trunk.)

Comment 46

[Marcia Knous [:marcia]]

https://litmus.mozilla.org/show_test.cgi?id=5198 added to litmus for ff3, i have an open bug about trying to get it added to ff 2 suite.

Comment 47

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12