[FIXr]Hover state remains active when onmouseout removechild is used

RESOLVED FIXED in mozilla1.8beta3

Status

()

RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: martijn.martijn, Assigned: bzbarsky)

Tracking

({regression, testcase})

Trunk
mozilla1.8beta3
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
In the url testcase, I see this happening for the links that have got a
'nicetitle', e.g. hovering over these links give a dhtml tooltip.
When I put my mouse over such a link and then scroll one mousescroll down with
my mousewheel (I have smooth scrolling turned off), the hover state of that link
remains active.
I believe I saw this particular issue with the url testcase, after bug 20022 was
fixed.

However, I'll attach a testcase that shows that this bug was there before that
(I can see it with the testcase even in Mozilla1.0)
(Reporter)

Comment 1

14 years ago
Created attachment 168776 [details]
Testcase

Comment 2

14 years ago
I'm seeing this also with the latest Firefox nightly:

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

Also of interest (whether or not it is exactly related to this bug or not, I'm
not sure) is that if you hover over one of the links in the testcase,
middle-click to open a new tab, and then close the new tab (so that you are back
to the original tab), the hover state will still be active until you mouse into
the content area.
(Reporter)

Comment 3

14 years ago
This bug is also WFM in 2005-03-29 build. Most likely fixed by bug 284664.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Depends on: 284664
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

14 years ago
This has regressed again in current trunk build.
The bug doesn't happen in a 2005-05-03 build, but it does happen in a 2005-05-04
build.
I suspect the fix for bug 292472 might be the culprit.
Blocks: 292472
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: WORKSFORME → ---
(Assignee)

Comment 5

14 years ago
So the problem here is that we move hover state from the target of the mouseout
to the target of the mouseover.  But the mouseout removes the mouseover target
from the DOM.  In that case, we end up with a null common ancestor; fine.  But
when we go to notify on content state changes, we get the document from the new
hover content (which is not in the document anymore).  So we don't send a
ContentStatesChanged notification.... If I fix that by using the "right"
document, then the red on the "Text" I'm leaving goes away, but the new "Text"
isn't highlighted.

If I just set the hover state to the mouseover node _before_ firing mouseout,
things seem to work.  Is that a reasonable approach?
(In reply to comment #5)
> If I just set the hover state to the mouseover node _before_ firing mouseout,
> things seem to work.  Is that a reasonable approach?

It's a bit counter-intuitive for anyone who's relying on side effects of the
hover state, but I can only think of a couple of possibilities for that: hover
state affecting layout affecting offsetX/Y etc, or people using :hover to attach
XBL. Neither of those seems very likely but I guess an alternative solution
would be better if one could be found...
(Assignee)

Comment 7

14 years ago
So the reason the new text isn't hightlighted if I just change the way I get the
document is that then the move event generated by the reflow doesn't find the
right document.

More generally, we have this weirdness where the ESM notifies content in other
documents at times...  Do we really need this for focus changes?  Isn't the ESM
in the newly-focused document going to get its own notifications as well?

In any case, I think the safe way to go is to not change the ordering of content
state changes and events but to fix the document-getting in SetContentState.
(Assignee)

Comment 8

14 years ago
Created attachment 183416 [details] [diff] [review]
Sorta-patch

This sort of does the least it can to make this testcase work...

I removed the assert because it's just clearly bogus given that nodes can be
removed from the document by the time we call this stuff on them.  That said,
though, perhaps we should check somewhere here that things are generally still
in the right document.	Calling SetContentState() on a node that's not even in
mDocument anymore seems somewhat odd to me...
Attachment #183416 - Flags: superreview?(roc)
Attachment #183416 - Flags: review?(roc)
Attachment #183416 - Flags: superreview?(roc)
Attachment #183416 - Flags: superreview+
Attachment #183416 - Flags: review?(roc)
Attachment #183416 - Flags: review+
(Assignee)

Comment 9

14 years ago
Comment on attachment 183416 [details] [diff] [review]
Sorta-patch

Requesting approval for a pretty straightforward fix to make sure we update the
:hover state right if the DOM is mutated under us.
Attachment #183416 - Flags: approval1.8b2?
(Assignee)

Updated

14 years ago
Assignee: nobody → bzbarsky
Status: REOPENED → NEW
OS: Windows 2000 → All
Hardware: PC → All
Summary: Hover state remains active when onmouseout removechild is used → [FIXr]Hover state remains active when onmouseout removechild is used

Comment 10

14 years ago
Comment on attachment 183416 [details] [diff] [review]
Sorta-patch

moving request out to b3. We're very nearly wrapped up on 1.8b2.
Attachment #183416 - Flags: approval1.8b3?
Attachment #183416 - Flags: approval1.8b2?
Attachment #183416 - Flags: approval1.8b2-
Comment on attachment 183416 [details] [diff] [review]
Sorta-patch

a=shaver
Attachment #183416 - Flags: approval1.8b3? → approval1.8b3+
(Assignee)

Comment 12

14 years ago
Fixed for 1.8b3.
Status: NEW → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
(Assignee)

Updated

14 years ago
Target Milestone: --- → mozilla1.8beta3
You need to log in before you can comment on or make changes to this bug.