Closed Bug 293914 Opened 19 years ago Closed 19 years ago

[FIXr]:hover state remains when ancestor of the hover content is removed

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

Attachments

(6 files)

See testcase coming up
Attached file Testcase
Attached patch PatchSplinter Review
The problem is that ContentRemoved is called only on the root of the subtree
being removed.
Attachment #183418 - Flags: superreview?(roc)
Attachment #183418 - Flags: review?(roc)
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
Attachment #183418 - Flags: superreview?(roc)
Attachment #183418 - Flags: superreview+
Attachment #183418 - Flags: review?(roc)
Attachment #183418 - Flags: review+
Comment on attachment 183418 [details] [diff] [review]
Patch

Another simple :hover fix when the DOM is being mutated.
Attachment #183418 - Flags: approval1.8b2?
Summary: [FIX]:hover state remains when ancestor of the hover content is removed → [FIXr]:hover state remains when ancestor of the hover content is removed
Comment on attachment 183418 [details] [diff] [review]
Patch

a=asa
Attachment #183418 - Flags: approval1.8b2? → approval1.8b2+
Fixed
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attached file testcase2 :active
So shouldn't this also be fixed for :active?
Attached patch Yeah, it shouldSplinter Review
With this patch, we correctly take the text out of :active when the mouse is
released after the kid has been removed.
Attachment #184154 - Flags: superreview?(dbaron)
Attachment #184154 - Flags: review?(dbaron)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [FIXr]:hover state remains when ancestor of the hover content is removed → [FIX]:hover state remains when ancestor of the hover content is removed
Comment on attachment 184154 [details] [diff] [review]
Yeah, it should

>   if (aContent == mLastMouseOverElement) {
>+    // XXXbz since this is just a recursion check, do we really want
>+    // to null this out here?
>     mLastMouseOverElement = nsnull;

Please replace this comment with a reference to bug 292146 (I was thinking I
should have added one then), and r+sr=dbaron.
Attachment #184154 - Flags: superreview?(dbaron)
Attachment #184154 - Flags: superreview+
Attachment #184154 - Flags: review?(dbaron)
Attachment #184154 - Flags: review+
Actually, you should probably fix that one too.
Attached patch Fix 'em allSplinter Review
Attachment #184167 - Flags: superreview?(dbaron)
Attachment #184167 - Flags: review?(dbaron)
Attachment #184167 - Flags: superreview?(dbaron)
Attachment #184167 - Flags: superreview+
Attachment #184167 - Flags: review?(dbaron)
Attachment #184167 - Flags: review+
Comment on attachment 184167 [details] [diff] [review]
Fix 'em all

requesting 1.8b2 approval for simple fix to more state handling when the DOM
mutates.
Attachment #184167 - Flags: approval1.8b2?
Summary: [FIX]:hover state remains when ancestor of the hover content is removed → [FIXr]:hover state remains when ancestor of the hover content is removed
Comment on attachment 184167 [details] [diff] [review]
Fix 'em all

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

a=shaver
Attachment #184167 - Flags: approval1.8b3? → approval1.8b3+
Fixed for 1.8b3.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.8beta2 → mozilla1.8beta3
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: