322338 - Hover state should not continuously cycle without mouse movement

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Greg K.]

Probably a dup, but I couldn't find it.

When the hover state restyles text so that the element is no longer in hover, and the unhovered state then restyles text so that the element is once again in hover, the cycle repeats indefinitely as fast as Gecko can draw it.

I propose that this cycle not occur unless the cursor is moved.

Testcase will be attached directly. This was tested using Win FF 1.5.

Comment 1

[Greg K.]

Attachment: XHTML testcase that easily demonstrates the issue

Comment 2

[Greg K.]

FYI, it appears Opera 8.5 behaves the way I propose in comment 0. That is, not cycling the hover state unless the mouse moves.

Comment 3

[Ria Klaassen (not reading all bugmail)]

I see a clear difference in behaviour between these two builds: 
1.8b_2005011915 and 1.8b_2005012010.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-19+14%3A00%3A00&maxdate=2005-01-20+10%3A00%3A00&cvsroot=%2Fcvsroot

Comment 4

[Greg K.]

(In reply to comment #3)
> I see a clear difference in behaviour between these two builds: 
> 1.8b_2005011915 and 1.8b_2005012010.

I would be surprised if this were as recent a problem as that. I've noticed this using builds since back in the FF 1.0 branch, though I only got around to constructing a testcase today.

Also reproduced using Camino 1.0b1, so setting All/All. Finally, Safari 2.0 appears to avoid the problem the same way as Opera and my recommendation.

Comment 5

[Greg K.]

Attachment: Revised XHTML testcase with clearer language

Comment 6

[Ria Klaassen (not reading all bugmail)]

Build 1.8b_2005011915 and before show similar behaviour as Opera: when I don't move my mouse at all, it does not flicker (neither the text nor the cursor). 

Comment 7

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

In Camino 0.8.4 (20050428, but built from the 1.7 branch), it will flicker (expand-contract due to bold->normal changing the length of the text) a little bit initially then finally decide on being non-bold and stop--but that initial flicker may just be the "margin of error" of my finger moving the pointer into the box and not stopping immediately. 

Comment 8

[Martijn Wargers (dead)]

It seems to me this is just the result of bug 20022 being fixed, so I would think this bug to be invalid.

Comment 9

[Greg K.]

(In reply to comment #8)
> It seems to me this is just the result of bug 20022 being fixed, so I would
> think this bug to be invalid.

Hm, don't be too sure. First, that bug was first and foremost about chrome. Second, properly handling hover states is important, but just constantly flickering back and forth between hover and nonhover makes no sense. There must be a better way.

Comment 10

[Hixie (not reading bugmail)]

If you have an element under the cursor, and it being in :hover makes it move away from the cursor, then it isn't in :hover anymore, is it. So we shouldn't style it as if it was. This isn't a bug. You would get the same effect with your suggestion if the user moved the mouse slowly. You would get the same effect if script on the page had an infinite loop. Etc.

Comment 11

[Greg K.]

(In reply to comment #10)
> If you have an element under the cursor, and it being in :hover makes it move
> away from the cursor, then it isn't in :hover anymore, is it. So we shouldn't
> style it as if it was. This isn't a bug. You would get the same effect with
> your suggestion if the user moved the mouse slowly. You would get the same
> effect if script on the page had an infinite loop. Etc.

Ian, I agree that's technically true. However, I don't believe it's entirely practical. I've encountered this bug on actual sites (including http://virtualvienna.net/) that made browsing using Gecko an unnerving experience.

Are you sure there isn't a compromise here?

Comment 12

[Hixie (not reading bugmail)]

Can anyone think of a compromise that wouldn't cause cases where authors have done the right thing to fail?

e.g. if a script moves a <div> under the cursor, :hover needs to update.

Comment 13

[Greg K.]

(In reply to comment #12)
> Can anyone think of a compromise that wouldn't cause cases where authors have
> done the right thing to fail?
> 
> e.g. if a script moves a <div> under the cursor, :hover needs to update.

Here are two ideas, I'm sure there are problems with each.

1. We could block cycling when the events are CSS-driven rather than script-driven (presuming it's possible to distinguish them)

2. We could count hover state changes since last mouse-move (hell, since last input event of any kind to account for keypresses as well) and not repeat

I keep thinking about your last sentence, though. Under what circumstances would we know that there were no longer any page scripts running or event handlers registered that would affect hover status?