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 27377 - MessageEvents in and out of workers should have origin set so we can have cross-origin workers at some point (and then you no longer need to special case same-origin workers)
Summary: MessageEvents in and out of workers should have origin set so we can have cro...
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/#workers
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-20 09:53 UTC by contributor
Modified: 2014-11-25 00:33 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2014-11-20 09:53:31 UTC 
Specification: https://html.spec.whatwg.org/multipage/workers.html
Multipage: https://html.spec.whatwg.org/multipage/#workers
Complete: https://html.spec.whatwg.org/#workers
Referrer: https://html.spec.whatwg.org/multipage/

Comment:
MessageEvents in and out of workers should have origin set so we can have
cross-origin workers at some point (and then you no longer need to special
case same-origin workers)

Posted from: 80.218.216.100 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 2 Ian 'Hixie' Hickson 2014-11-20 20:42:15 UTC 
That seems contrary to the capabilities model that Workers are intended to provide. Can you elaborate on how you would use this origin? Suppose someone creates a channel in one worker and sends the port back to the page, then later decides it should actually implement its side of the contract by offloading the work to another work. Should the origin change if the other worker in question is in another origin? (This can happen today using iframes, e.g.)
Comment 3 Anne 2014-11-21 07:00:33 UTC 
Interesting. I had forgotten about it being capability-based.
Comment 4 Ian 'Hixie' Hickson 2014-11-21 23:59:59 UTC 
So does that mean this is WONTFIX?
Comment 5 Brad Hill 2014-11-22 00:08:34 UTC 
Why shouldn't the behavior be the same for workers as for iframes?
Comment 6 Ian 'Hixie' Hickson 2014-11-24 18:44:41 UTC 
The behaviour _is_ the same, no? MessagePort doesn't care where the message comes from. Am I missing something?
Comment 7 Brad Hill 2014-11-25 00:33:06 UTC 
I think I understand now - the default channel associated with a worker, accessible via postMessage(), is a MessageChannel.  It does not set the origin of messages because it is not being invoked on a Window object.  I see this behavior is consistent with iframes.

Thanks for the patience.  Anne is quicker at opening bugs than I am at building out my test matrix and understanding all the nuances of what they're telling me.  :)