271479 - {inc}Mouse down interferes with :hover

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Paul McGarry]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122

Not sure whether this is an events or a layout bug (or maybe style?).

Will follow up with a simplified testcase in a second.

Reproducible: Always
Steps to Reproduce:
(skip 1 and 2 if using the test case)
1. Go to http://paulmcgarry.com/
2. Click on the link for the "purple" page style.
3. Mouse over the "Page style" and click on another style.

Actual Results:  
The DIV shrinks back, the clicked on link seems to scroll up and be selected but
doesn't fire the javascript onclick event.

Expected Results:  
The DIV shouldn't shrink. No scrolling should occur. onclick event should fire. 

When the mouse button is pushed down Mozilla seems to forget that the mouse
pointer is over the div with class="style" and reverts it to it's non :hover state.

Shrinking the div and moving the link out from under the mousepointer means the
click doesn't trigger when the mouse button up occurs.

Comment 1

[Paul McGarry]

Attachment: Simplified testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Is every single bit of that CSS really needed?

Chances are, this is an issue with scrollframes (so removing the overflow
setting will fix it, but other settings can be removed without the bug
disappearing).

Comment 3

[Paul McGarry]

Attachment: Even simpler testcase

Trimmed superfluous CSS/html.

Comment 4

[Paul McGarry]

Attachment: Same testcase without absolute positioning, doesn't trigger problem

(In reply to comment #2)
> Chances are, this is an issue with scrollframes (so removing the overflow
> setting will fix it, but other settings can be removed without the bug
> disappearing).

The absolute positioning seems to be relevant too. The updated testcase without
absolute positioning CSS doesn't reveal the problem.

Comment 5

[Caleb]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050428
Firefox/1.0+

WFM.

Comment 6

[Paul McGarry]

Caleb, did you try the right test case, the "Even simpler testcase" one?
It is still broken for me with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050428

Comment 7

[Paul McGarry]

Sounds like it really does work for Caleb. Why not for me?

On 4/29/05, Caleb <[e-mail]> wrote:
> Hmm.. yeah, maybe I didn't get what you mean.
>
> I've tested the "Even simpler testcase":
>  - Mouse over the "Hover" text, the DIV expands
>  - Click the "Click" link, I get an alert

Hmm, that sounds like what should happen. It doesn't for me though

What happens for me is:
- Mouse over the "Hover" text, the div expands.
- Click the "click" link, immediately (on mouse down, before click is
finished) the div 'shrinks' again but now the "Click" text is visible
(and red in colour) in the div as if the div contents have scrolled
up. When the click completes the alert is not triggered.

If it works for you and not for me using the same build then perhaps
it's some sort of race condition and this computer is a bit slow (I
think it's a Pentium III 866)?

Comment 8

[Martijn Wargers (dead)]

wfm for me now with a build with the fix for bug 240276.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Paul and Caleb, make sure to list the build HOUR when commenting about builds
from the day when a bug was fixed.  Firefox nightlies are built in the evening,
while Seamonkey ones are built in the morning, so builds with the same _date_
but a different _hour_ can have quite different behavior.

Comment 10

[Caleb]

(In reply to comment #9)

Yeah, sorry about that bz.. I only came here after bug 240276 was fixed :)

Would be nice if tinderbox builds had the hour somewhere ...

Comment 11

[Boris Zbarsky [:bzbarsky]]

When you download the build, download from one of the "dated" FTP dirs.  Or at
least look at the FTP timestamp; that will give you an approximation of the hour.