This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27209 - "Create an event that uses the MessageEvent interface" Why not set the source for a message event in a MessageChannel?
Summary: "Create an event that uses the MessageEvent interface" Why not set the source...
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: https://html.spec.whatwg.org/#transfe...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-31 13:21 UTC by contributor
Modified: 2014-11-06 08:31 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2014-10-31 13:21:37 UTC 
Specification: https://html.spec.whatwg.org/multipage/comms.html
Multipage: https://html.spec.whatwg.org/multipage/#transferMessagePort
Complete: https://html.spec.whatwg.org/#transferMessagePort
Referrer: 

Comment:
"Create an event that uses the MessageEvent interface" Why not set the source
for a message event in a MessageChannel?

Posted from: 46.127.136.57 by annevk@annevk.nl
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Comment 1 Ian 'Hixie' Hickson 2014-11-04 00:36:08 UTC 
Can you elaborate? Set it to what? Why?
Comment 2 Anne 2014-11-04 08:45:54 UTC 
To the source port. Checking with baku if that's really necessary; looking at it closer it seems that if you have a port you have both onmessage and postMessage available, and no real need for e.source.
Comment 3 Anne 2014-11-04 10:35:12 UTC 
baku's argument is that since we know the source we should just set it to that, even if it's redundant with e.target.

(Not sure, but perhaps this will make it slightly easier to write consistent message handling code?)
Comment 4 Ian 'Hixie' Hickson 2014-11-06 00:41:12 UTC 
The source of a message is the object on which postMessage() was called. That might be in a different worker. We don't want the behaviour to be different based on whether the source is in the same worker or not, since that can hurt later refactoring into multiple workers, which we generally want to encourage.