The default bug view has changed. See this FAQ.

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

VERIFIED FIXED

Status

Core Graveyard
Widget: Mac
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: marcia, Assigned: smichaud)

Tracking

({verified1.8.1.10})

1.8 Branch
All
Mac OS X
verified1.8.1.10
Bug Flags:
blocking1.8.1.10 +
in-testsuite ?
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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

10 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

10 years ago
Created attachment 286585 [details]
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

10 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

10 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

10 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

10 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

10 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

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

Comment 12

10 years ago
Any ideas for workarounds?
When started it working on trunk?
(Assignee)

Comment 14

10 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

10 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

10 years ago
Hardware: PC → All
This became fixed on trunk when Cocoa widgets landed on September 28, 2006.
(Assignee)

Comment 17

10 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

10 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

10 years ago
Steven - any updates?
(Reporter)

Comment 20

10 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

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

10 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

10 years ago
Created attachment 287254 [details] [diff] [review]
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:21-smichaud@pobox.com-bugzilla400082/smichaud@pobox.com-bugzilla400082-firefox-try-mac.dmg
Attachment #287254 - Flags: review?(joshmoz)
(Reporter)

Comment 25

10 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

10 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

10 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

10 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

10 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

10 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.
Flags: blocking1.8.1.9?

Comment 31

10 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

10 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?
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+
(Assignee)

Comment 34

10 years ago
Landed on the 1.8 branch with Josh's code change and some revisions to
the comments.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Adding fixed keyword.
Keywords: fixed1.8.1.10
(Reporter)

Comment 36

10 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

Updated

10 years ago
Duplicate of this bug: 401636

Updated

10 years ago
Duplicate of this bug: 403135
Duplicate of this bug: 403353

Comment 40

10 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

10 years ago
is this a problem on trunk, too?

Comment 42

10 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 :(

Duplicate of this bug: 404701

Comment 44

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

9 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+
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

Updated

7 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.