Closed Bug 400082 Opened 16 years ago Closed 16 years ago

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

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Version:
1.8 Branch
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: marcia, Assigned: smichaud)

References

(
URL
)

Details

(Keywords: verified1.8.1.10)

Attachments

(2 files)

Test case demonstrating broken behavior in OS X 10.5
6.28 KB, application/zip
Details
Fix
4.89 KB, patch
jaas
: review+
roc
: superreview+
dveditz
: approval1.8.1.10+
Details | Diff | Splinter Review 
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.
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.
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.
Here's a QuickTime video demonstrating the test case in attachment 286585 [details]:
http://s3.amazonaws.com/sstephenson/public/mozilla-400082.mov

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.
Forum topic with more info from users that have hit this bug: http://forums.mozillazine.org/viewtopic.php?t=597793
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.
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!
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.
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
Flags: blocking1.8.1.9?
Flags: blocking1.8.1.10?
Did this ever work in FF2008?
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.
Any ideas for workarounds?
When started it working on trunk?
I'm going to start trying to find a fix for this.  I hope to have
something more definite to say by sometime tomorrow.
Assignee: joshmoz → smichaud
> 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 :-)
Hardware: PC → All
This became fixed on trunk when Cocoa widgets landed on September 28, 2006.
(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.
Hardware: All → PC
> 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.

Steven - any updates?
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.
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.

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 ...
I'm about to post a fix for this, and an explanation.

Can you hold on for about an hour? :-)
Attached patch Fix — — Splinter Review 
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:21-smichaud@pobox.com-bugzilla400082/smichaud@pobox.com-bugzilla400082-firefox-try-mac.dmg
Attachment #287254 - Flags: review?(joshmoz)
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.

> 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.

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!
> 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 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.
Attachment #287254 - Flags: superreview?(roc)
Attachment #287254 - Flags: review?(joshmoz)
Attachment #287254 - Flags: review+
> 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.
Flags: blocking1.8.1.9?
(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.
Attachment #287254 - Flags: superreview?(roc) → superreview+
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.
Attachment #287254 - Flags: approval1.8.1.10?
Flags: blocking1.8.1.11? → blocking1.8.1.10+
Comment on attachment 287254 [details] [diff] [review]
Fix

approved for 1.8.1.10, a=dveditz for release-drivers
Attachment #287254 - Flags: approval1.8.1.10? → approval1.8.1.10+
Landed on the 1.8 branch with Josh's code change and some revisions to
the comments.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Adding fixed keyword.
Keywords: fixed1.8.1.10
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.
Keywords: fixed1.8.1.10 → verified1.8.1.10
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.
is this a problem on trunk, too?
(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 :(


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.
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.)
Flags: in-testsuite?
Flags: in-litmus?
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.
Flags: in-litmus? → in-litmus+
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
Status: RESOLVED → VERIFIED
Hardware: PC → All
Product: Core → Core Graveyard
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.