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?
(In reply to comment #3) > Created an attachment (id=208993)  > 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.
Smaug, I haven't thought about this in a while; do you want to take it?
Assignee: ajvincent → Olli.Pettay
Status: ASSIGNED → NEW
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.
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.
Comment on attachment 228992 [details] [diff] [review] proposed patch Looks good, r+sr=jst
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
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.