343302 - Single-click on long <select> drop-down menus doesn't keep menu open

Status: VERIFIED WORKSFORME

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Peter Jaros (:peeja)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060629 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060629 Camino/1.0+

Clicking on the P-Z drop-down on the given page often opens and closes the menu, rather than opening and staying open in sticky-menu mode.

I believe this is has something to do with the time it takes to bring up the long menu.  It happens most when the control is near the bottom of the window, causing the menu to appear above the control, and displaying a very large number of items.  My theory is that if the mouseup event comes before a certain point in the loading, the menu is dismissed immediately.  However, if the mouseup comes too late, the menu is not in sticky mode, so it is also dismissed immediately.  I am on a slower machine, an iBook G3 with 384 MB of RAM.

Reproducible: Sometimes

Steps to Reproduce:
1. Click on the P-Z list on the given page.  Works best when the control is near the bottom of the window.  Vary the length of clicks until it works.
Actual Results:  
Menu goes away immediately.

Expected Results:  
Menu stays up until dismissed.

Comment 1

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

I mentioned this on irc, but this menu drops down immediately for me and then stays down.  My guess is that this is slow hardware-related, and other than pawn and this replacement iBook, there's not that much of that hardware left.

Comment 2

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

I actually saw this bug on some page the other day (and failed to note the URL or connect it to this bug) :/

Comment 3

[Chris Lawson (gone)]

WFM. Peter, if either you or Smokey sees this again, please re-open it.

cl

Comment 4

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

Reopening.  I see this at http://www.securityfocus.com/vulnerabilities (the "Select Vendor" select), and Sam does, too.  Ian doesn't, oddly.

It'd be great if we could get a real reduced testcase for this, though....

Comment 5

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

Attachment: Testcase

I can reproduce fairly consistently (90% of the time) with this testcase. If you single click the select (click and release), it "blinks" and shows closed. Sometimes it works fine though, but that behavior is very rare.

I reduced the amount of options in the select, which may be why it doesn't happen every time. The link Smokey gave shows it every time for me.

Comment 6

[philippe (part-time)]

OK, I see something else (with a trunk build).
While the test case loads, the select changes size, grows a bit, shrinks a bit before settling on the final width. Once it is fully loaded, and after clicking, there is a short but visible delay before the options appear. But no other problems on my side. If I access the dropdown from the keyboard, it responds immediately.

In Firefox 2.0, the size is set immediately, and no delay on click. Safari 2.0 has a similar problem ( short delay) when clicking on the menu.

No open-close dance on my side. Click and the menu stays open.

Comment 7

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

We determined in channel (between Smokey, Ian, and I) that this only is visible on the branch and appears to be fixed on the trunk.

On the branch, the results are inconsistent. Sometimes it happens, sometimes it doesn't. Though, it usually tends to happen more than not.

I also see the slowness Phillipe reports in comment 6, but not the resize stuff.

Unless someone wants to track down when this bug was fixed on trunk -- and by what bug -- so we can mark it as FIXED, I think we can probably mark this as WORKSFORME again. This probably won't be fixed on the branch given that it appears fixed on the trunk.

Comment 8

[philippe (part-time)]

Strange things.
I tried to track down when the behaviour changed on trunk.

Using a Camino 20050812 (Gecko rv 1.8b4) this works correctly both on 10.3.9 and 10.4.8.
The 1.8 branch was cut on 20050812 (the Camino 0813 build is Gecko 1.9a1).
But Camino 1.03 and the latest nightlies from Branch show the problem clearly on 10.3.9 (running on a slow Mac [1]). My test running the branch on 10.4.8 [2] are inconclusive. Sometimes yes, sometimes not; mostly correct.
All trunk builds (using Gecko 1.9a1) behave correctly on both 10.3.9 and 10.4.8.

I see the resizing thing while loading both on Camino trunk and Minefield, as long as the page is not cached; once cached no problems anymore. I checked what happened on my reflow branch build (20061030), and no problems there.

'correct' in the above means the menu opens on a single click and stays open as needed. All builds show a slight delay while opening. 2700+ options...

Next: find a regression range on the 1.8 branch, I suppose.

[1] PPC 10.3.9, Dual 450Mhz, 640Mb  Ram
[2] PPC 10.4.8, PowerBook 1.5Ghz, 1.5Gb Ram.

Comment 9

[froodian (Ian Leue)]

Although we can't always repro this reliably, it certainly happens.  Confirming.

Comment 10

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

I think the likelihood of this getting fixed on the branch is very low, and it's certainly not a priority for us for 1.6.  Given that, let's go and do what Sam says in comment 7.

If someone feels like taking this on, feel free to reopen and do so; otherwise, the WFM on the trunk.