369644 - text inputs trigger spurious mouseout/mouseovers at the border

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[timeless]

because of the widget impl, there's a native anonymous frame between the border and the text area (or something like that) which means that when you drag your mouse across a text widget, instead of getting:

[Over], [Out]

you get:
[Over, Out, Over], [Out, Over, Out]

Comment 1

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

Attachment: testcase

Comment 2

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

Attachment: possible patch

This prevents mouseover/out propagation when they are happening 
somewhere in native anonymous content. I think the events should
be still dispatched normally, but just not propagated to
non-native-anon.
The patch is more complex than I'd like, but there are quite many 
cases to handle (when target is in native-anon, when related target is 
in native-anon, when both are in native-anon, but don't have the same
non-native-anon parent etc.)
mRelatedTargetIsInAnon is needed to reduce calls to IsInAnonContent
to max 1 per event.

Comment 3

[Johnny Stenback (:jst)]

Comment on attachment 254359 [details] [diff] [review]
possible patch

r=jst

Comment 4

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

Comment on attachment 254359 [details] [diff] [review]
possible patch

> nsGenericElement::doPreHandleEvent(nsIContent* aContent,
>                                    nsEventChainPreVisitor& aVisitor)
> {
>   //FIXME! Document how this event retargeting works, Bug 329124.
>   aVisitor.mCanHandle = PR_TRUE;
>+
>+  // Don't propagate mouseover and mouseout events when mouse is moving
>+  // inside native anonymous content.
>+  PRBool isAnonForEvents = aContent->IsAnonymousForEvents();
>+  if (aVisitor.mEvent->message == NS_MOUSE_ENTER_SYNTH ||
>+      aVisitor.mEvent->message == NS_MOUSE_EXIT_SYNTH) {
>+     nsCOMPtr<nsIContent> relatedTarget =
>+       do_QueryInterface(NS_STATIC_CAST(nsMouseEvent*,
>+                                        aVisitor.mEvent)->relatedTarget);
>+    if (relatedTarget &&
>+        relatedTarget->GetOwnerDoc() == aContent->GetOwnerDoc()) {

Note that this'll test true if both GetOwnerDoc calls return nsnull, is that a problem? GetOwnerDoc returns null if the document gets GC'ed while someone still holds a reference to the element.

sr=me if that's ok.

Comment 5

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

I can't think any cases where null ownerdoc would be a problem, because
either target or related target must be in nativeAnonContent, otherwise
the event is handled normally. And dispatching to an nsIContent which doesn't have ownerDoc sounds quite strange, though maybe possible.

I don't know if it is possible to write a mochitest for this bug.