438241 - Mousover and mouseout don't behave with nested elements.

Status: VERIFIED FIXED

(Core :: DOM: Events, defect, P1)

Description

[RMM]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0

Try this example that demonstrates the problem:
http://eyestreet.com/~rmcgeary/test-hover-ff3.html


Reproducible: Always

Steps to Reproduce:
1. Try hovering over the input elements in the example.
2. Continue to move the mouse over the input elements until more than one element is left red.
Actual Results:  
In Firefox 3 RC2, some elements are left red even though the mouse has left those elements.

Expected Results:  
Upon hover (mouseover) of any element, the background color should be made red. Mouseout should return the background color to white.

Comment 1

[José Jeria]

Attachment: Reporters testcase

Comment 2

[José Jeria]

Confirming on Windows 2000.

Comment 3

[Ria Klaassen (not reading all bugmail)]

Just like bug 436930, coincidentally filed a few days ago, this is a regression from bug 369644.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Looks like a regression between 2007-05-13-01 and 2007-05-14-01.

Bonsai log:  http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-13+01&maxdate=2007-05-14+01&cvsroot=%2Fcvsroot

Looks like a regression from bug 369644.  This is pretty nasty....

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Attachment: proposed patch.

The real change here is adding an extra IsInNativeAnonymousSubtree().
That way scrollbar handling on bug 369644 doesn't regress and I can't see
this bug anymore. Changed some naming too.

-            if (nonAnon == nonAnonRelated ||
-                nsContentUtils::ContentIsDescendantOf(nonAnonRelated, nonAnon)) {
+            if (anonOwner == anonOwnerRelated ||
+                (anonOwnerRelated->IsInNativeAnonymousSubtree() &&
+                 nsContentUtils::ContentIsDescendantOf(anonOwnerRelated,
+                                                       anonOwner))) {

The patch should be very safe - at least it shouldn't break anything more
than what is now since it is limiting the cases when
we stop event propagation.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v2

Tricky to handle all the cases, so I eventually had to add
that
relatedTarget->FindFirstNonNativeAnonymous() == originaltarget->FindFirstNonNativeAnonymous()
That makes sure we never stop propagation when we shouldn't.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Could this be the same as bug 436930? We've got a good testcase here so marking blocking.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 324599 [details] [diff] [review]
v2

Jonas, could you sr?

Comment 9

[RMM]

This regression seems like a big deal and drastically affects my own web development.  I'm extremely disappointed this didn't block the release of Firefox 3.  The avoidance of basic event handling gives a bad name to such a great project.  This seriously taints an otherwise great release.

What can I do to help move this fix forward?

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 324599 [details] [diff] [review]
v2

Is FindNativeAnonymousSubtreeOwner something we want to expose on nsIContent?

sr=me either way.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Is this ready to get nominated for approval1.9.0.1?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

I commited this to trunk already June 23.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 324599 [details] [diff] [review]
v2

If this gets to 1.9.0.x, so should Bug 445416. Both have had some baking time.

Comment 14

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

QA: If/when this gets fixed in 1.9.0.x, please verify bug 436930 as well.

Comment 15

[Daniel Veditz [:dveditz]]

Comment on attachment 324599 [details] [diff] [review]
v2

not approved for 1.9.0.4, doesn't meet the new stricter criteria. Users will get this in 3.1

Comment 16

[Aakash Desai [:aakashd]]

Changesets for the bug:

http://hg.mozilla.org/mozilla-central/rev/b1600c01c443

and 

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b1600c01c443

Comment 17

[Aakash Desai [:aakashd]]

verified FIXED after about 20 hover-streaks over the set of textfields...on builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090406045355

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090331 Shiretoko/3.5b4pre (.NET CLR 3.5.30729) ID:20090331041754