initMouseEvent does not set relatedTarget property

RESOLVED FIXED

Status

()

Core
DOM: Events
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Jason Davis, Assigned: smaug)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
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
jkd: testcase HTML file? :-)
Oh ho... nsDOMMouseEvent::InitMouseEvent accepts the argument, but doesn't do anything with it.

This one looks easy to fix.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
Created attachment 208993 [details] [diff] [review]
patch, v1

This patch fixes the bug and exposes the related target.  bz?
Assignee: events → ajvincent
Status: NEW → ASSIGNED
Attachment #208993 - Flags: superreview?(bzbarsky)
Attachment #208993 - Flags: review?(bzbarsky)
(Assignee)

Comment 4

13 years ago
(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 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.
Attachment #208993 - Flags: superreview?(bzbarsky)
Attachment #208993 - Flags: superreview-
Attachment #208993 - Flags: review?(bzbarsky)
Attachment #208993 - Flags: review-
Smaug, I haven't thought about this in a while; do you want to take it?
(Assignee)

Comment 7

12 years ago
sure
Assignee: ajvincent → Olli.Pettay
Status: ASSIGNED → NEW
(Assignee)

Comment 8

12 years ago
Created attachment 228990 [details]
A test for mouseover events
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.
(Assignee)

Comment 10

12 years ago
Created attachment 228992 [details] [diff] [review]
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.
Attachment #228992 - Flags: superreview?(jst)
Attachment #228992 - Flags: review?(jst)
(Assignee)

Comment 11

12 years ago
(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"
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Comment on attachment 228992 [details] [diff] [review]
proposed patch

Looks good, r+sr=jst
Attachment #228992 - Flags: superreview?(jst)
Attachment #228992 - Flags: superreview+
Attachment #228992 - Flags: review?(jst)
Attachment #228992 - Flags: review+
(Assignee)

Updated

12 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 13

11 years ago
Any chance of this getting onto MOZILLA_1_8_BRANCH. This is serious breakage for any listeners that want to use relatedTarget.
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).
You need to log in before you can comment on or make changes to this bug.