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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: marcia, Assigned: smichaud)
References
()
Details
(Keywords: verified1.8.1.10)
Attachments
(2 files)
6.28 KB,
application/zip
|
Details | |
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.
Comment 1•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
Here's a QuickTime video demonstrating the test case in attachment 286585 [details]: http://s3.amazonaws.com/sstephenson/public/mozilla-400082.mov
Reporter | ||
Comment 4•16 years ago
|
||
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.
Reporter | ||
Comment 5•16 years ago
|
||
Forum topic with more info from users that have hit this bug: http://forums.mozillazine.org/viewtopic.php?t=597793
Reporter | ||
Comment 6•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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?
Updated•16 years ago
|
Flags: blocking1.8.1.10?
Comment 10•16 years ago
|
||
Did this ever work in FF2008?
Comment 11•16 years ago
|
||
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•16 years ago
|
||
Any ideas for workarounds?
Comment 13•16 years ago
|
||
When started it working on trunk?
Assignee | ||
Comment 14•16 years ago
|
||
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
Assignee | ||
Comment 15•16 years ago
|
||
> 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 :-)
Updated•16 years ago
|
Hardware: PC → All
Comment 16•16 years ago
|
||
This became fixed on trunk when Cocoa widgets landed on September 28, 2006.
Assignee | ||
Comment 17•16 years ago
|
||
(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
Assignee | ||
Comment 18•16 years ago
|
||
> 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•16 years ago
|
||
Steven - any updates?
Reporter | ||
Comment 20•16 years ago
|
||
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.
Assignee | ||
Comment 21•16 years ago
|
||
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•16 years ago
|
||
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 ...
Assignee | ||
Comment 23•16 years ago
|
||
I'm about to post a fix for this, and an explanation. Can you hold on for about an hour? :-)
Assignee | ||
Comment 24•16 years ago
|
||
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)
Reporter | ||
Comment 25•16 years ago
|
||
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.
Assignee | ||
Comment 26•16 years ago
|
||
> 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•16 years ago
|
||
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!
Assignee | ||
Comment 28•16 years ago
|
||
> 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•16 years ago
|
||
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+
Assignee | ||
Comment 30•16 years ago
|
||
> 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.
Updated•16 years ago
|
Flags: blocking1.8.1.9?
Comment 31•16 years ago
|
||
(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+
Assignee | ||
Comment 32•16 years ago
|
||
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?
Updated•16 years ago
|
Flags: blocking1.8.1.11? → blocking1.8.1.10+
Comment 33•16 years ago
|
||
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+
Assignee | ||
Comment 34•16 years ago
|
||
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
Reporter | ||
Comment 36•16 years ago
|
||
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
Comment 40•16 years ago
|
||
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•16 years ago
|
||
is this a problem on trunk, too?
Comment 42•16 years ago
|
||
(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•16 years ago
|
||
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•16 years ago
|
||
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?
Reporter | ||
Comment 46•16 years ago
|
||
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+
Comment 47•16 years ago
|
||
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
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (abuse, spam) |
Comment hidden (abuse, spam) |
Updated•3 years ago
|
Restrict Comments: true
You need to log in
before you can comment on or make changes to this bug.
Description
•