311601 - Pulldown menus on Slashdot don't work and/or disappear

Status: RESOLVED DUPLICATE of bug 313988

(Firefox :: General, defect)

Description

[HJ]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Using FF 1.5b2, the pulldown menus in the discussion threads of Slashdot
(Threshold, Threaded/Nested/Flat/No Comments, Highest Scores First/Newest
First/etc.) are not working.

Clicking on the pulldown menu (either the text or the down-arrow) does not pull
the menu down. Multiple clicks don't do anything. Most importantly,
**option-clicking makes the menu disappear altogether**. (It comes back with a
page reload, though.)

The only way I have been able to get them to work is to click once to
"highlight" a given menu, then use the up-arrow and down-arrow keys to page
through the options.

Obviously these work correctly in FF 1.0.7.

(Will attach a screenshot with one or two menus "disappeared" shortly.)

Reproducible: Always

Steps to Reproduce:
1. Go to slashdot.
2. Click on a story to get to the discussion thread.
3. Try to change the default values (Threshold:1, Nested, Oldest First) to
something else by operating the pulldowns.

Actual Results:  
Pulldowns don't so much pull down.

Expected Results:  
Pulldowns should pull down.

Screenshot with the second and third menus disappeared attached.

Comment 1

[HJ]

Attachment: missing slashdot menus

how it looks when loading the page initially

Comment 2

[HJ]

Attachment: normal slashdot menus (initial page load)

oops -- that first attachment was the *missing* screenshot. this is what the
page looks like upon the initial load.

Comment 3

[HJ]

CORRECTION: It's option-shift-doubleclick to make them disappear, not option-click.

Comment 4

[HJ]

Attachment: menus vanished on bugzilla bug page

looks like it's not limited to slashdot. attachment shows the same problem with
this very bug report page.

Comment 5

[Steuard Jensen]

I'm using Firefox 1.5RC1: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

I have not been able to reproduce the "vanishing" menu issue reported here, with any combination of shifts, options, clicks, or double clicks.

But I can emphatically confirm that clicking on pulldown menus (<select> form elements) on Slashdot comment pages fails to make the menu drop down as it should.  As described by the original reporter, clicking still gives the menu focus, so you can use the arrow keys to make your choice.  (After clicking, the menu looks exactly the way it would if you had clicked on it twice, including the extra outline showing that it still has focus.)

I have tested this with a clean profile, and the behavior is still there.  I have no idea what it is about Slashdot in particular that causes this bug, but if it happens there, it's sure to happen elsewhere as well.  This is a major usability regression, and I would really like to see it get fixed in 1.5 (late in the day though it is).

Comment 6

[:Gavin Sharp [email: [e-mail]]]

The shift clicking is a feature of AdBlock that lets you easily remove items from the page. he drop downs work fine for me using the latest branch build on Windows.

Comment 7

[Marcia Knous [:marcia]]

Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5, I see the problem when I shift-option-click (and I do have Adblock installed.) But the drop downs work fine otherwise.

Comment 8

[Steuard Jensen]

Attachment: Testcase (simplified version of a slashdot page)

This attachment is a very stripped down version of a Slashdot comment page.  On my browser, it demonstrates several significant points about the bug:

1. The bug depends on the form being contained in a block with "position: relative", even if no explicit position is set.

2. The bug also changes depending on the left margin of a <div> containing the form.  At least on my computer, this testcase shows an example where the menu is *partly* visible (only the leftmost edge of the dropdown menu is visible).  But a small change in the margin can produce a much larger change in the fraction of the dropdown menu that is visible.  (Try changing the testcase margin from 4.8em to 4.7em: much more than 0.1em more of the menu becomes visible.)  Changing what else appears on the page changes these details as well (when I tried adding some text before the first <div>, the dropdown menu disappeared entirely rather than being partially displayed).

3. The bug does not occur unless *two* script elements with "src" attributes preceed the form, even if those are just 'src=""'.  (It's not significant that the script elements are immediate prior siblings of the form as in this testcase; on the original page, they were encased in several extra layers of <div>s.)

I hope this helps.

Comment 9

[Steuard Jensen]

I just tested the above testcase with a build from CVS as of about half an hour ago and a clean profile, and I get the behavior described above (a dropdown menu that's only partially visible).  The build ID was:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051109 Firefox/1.5

I guess we're too late to get this fixed for 1.5, eh?

Comment 10

[Steuard Jensen]

Attachment: Screenshot of partially visible dropdown menu

This screenshot shows the partially displayed dropdown menu as described above in comment #8.  The screenshot is taken from the same CVS build (with brand new profile) described in comment #9, but the behavior shown is identical to what I see in my official 1.5RC1 binary.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I can reproduce the Slashdot selects failing to drop down in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5, with a fresh profile.

The testcase, however, works fine for me, again with a fresh profile.
 
(This bug also *doesn't* happen in the identical version of Camino, but we do have a bug like it, bug 312924, which works in Fx....)

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sorry, I didn't mean to reset the blocking? flag; there must have been some sort of Bugzilla hiccup when I posted my comment yesterday....

Comment 13

[Steuard Jensen]

Attachment: Testcase 2 (should more reliably reproduce the problem)

Regarding comment #11, I'm not sure why my first testcase isn't working for you, but my guess is that it's related to the precise choice of left margin there.  As I mentioned in comment #8, the effect seems to be very sensitive to exactly how large the margin is, and I tuned that first testcase to yield the "cut off menu" behavior shown in the screenshot in my particular browser.

This new testcase has a substantially larger left margin (even larger than the original on slashdot, I believe), and thus I expect it to fail for anyone who sees the slashdot bug.  If you're still not seeing the problem, I suggest downloading the HTML file and making the left margin larger yet.

Oh, and in case it's relevant, I'm running Mac OS 10.3 (or rather, whichever minor version update is most current right now).

Comment 14

[Stefan [:stefanh]]

This sounds like the same issue as bug 313988. See https://bugzilla.mozilla.org/show_bug.cgi?id=313988#c14 for a possible regression range. 

Comment 15

[Stefan [:stefanh]]

I'm duping this bug against 313988 (there are som mac folks cc:ed there). I'll transfer the testcae. The regression range is the same, both for slashdot menus and the testcase: It works in a build from 29th of september, but does not work in a build from 30th of september (with mac os 10.3.9)

Comment 16

[Stefan [:stefanh]]

Hmm, forgot to dupe...

*** This bug has been marked as a duplicate of 313988 ***