324011 - initMouseEvent does not set relatedTarget property

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Jason Davis]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051202 Camino/1.0b1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051202 Camino/1.0b1+

When calling initMouseEvent() on a newly created event (document.createEvent("MouseEvents")), the related target property is always set to null (regardless of what I provide for arguments). The correct behavior of course would be to have event.relatedTarget equal to whatever the last argument in initMouseEvent was.

I can also confirm on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051119 Firefox/1.6a1.

Reproducible: Always

Comment 1

[Alex Vincent [:WeirdAl]]

jkd: testcase HTML file? :-)

Comment 2

[Alex Vincent [:WeirdAl]]

Oh ho... nsDOMMouseEvent::InitMouseEvent accepts the argument, but doesn't do anything with it.

This one looks easy to fix.

Comment 3

[Alex Vincent [:WeirdAl]]

Attachment: patch, v1

This patch fixes the bug and exposes the related target.  bz?

Comment 4

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

(In reply to comment #3)
> Created an attachment (id=208993) [edit]
> patch, v1
> 
> This patch fixes the bug and exposes the related target.  bz?
> 
I don't think this is the right way to fix the problem.
If a mouseevent is initialized while there is one event being
dispatched, this would change the relatedTarget of that event.
And it should be possible to set the relatedTarget even if there is no prescontext.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 208993 [details] [diff] [review]
patch, v1

No, this is wrong.  Consider initing but NOT dispatching an event in an event handler.  That will overwrite the relatedTarget of the event you are currently handling.

The way to fix this, imo, is to stop the braindamage of storing the relatedTarget in global state in the ESM and just store it in the event itself.

Comment 6

[Alex Vincent [:WeirdAl]]

Smaug, I haven't thought about this in a while; do you want to take it?

Comment 7

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

sure

Comment 8

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

Attachment: A test for mouseover events

Comment 9

[Alex Vincent [:WeirdAl]]

smaug: I don't think your testcase actually is testing what this bug is about.  Per comment 0, the event in question is created by script, not by user actions.

Comment 10

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

Attachment: proposed patch

Make mouse and mousescroll events to own relatedTarget.
mousescroll events need it only because someone may reinitialize event and 
(re-)set the related target.

Comment 11

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

(In reply to comment #9)
> smaug: I don't think your testcase actually is testing what this bug is about. 
> Per comment 0, the event in question is created by script, not by user actions.
> 

The javascript: test case is testing relatedTarget when using init*Event, 
my testcase is just to make sure that the patch works also with "user actions"

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 228992 [details] [diff] [review]
proposed patch

Looks good, r+sr=jst

Comment 13

[Colin Blake]

Any chance of this getting onto MOZILLA_1_8_BRANCH. This is serious breakage for any listeners that want to use relatedTarget.

Comment 14

[Martijn Wargers (dead)]

No chance, the patch is changing the event state manager interface, so it could possibly break things if it went into the 1.8 branch.
Also, this is not a critical bug (it isn't a crash or a security issue).