This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html Multipage: http://www.whatwg.org/C#sandboxOrigin Complete: http://www.whatwg.org/c#sandboxOrigin Comment: The origin of documents not in a browsing context is wrong in the spec Posted from: 173.48.81.109 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20121213 Firefox/20.0
At the very least this part: If a Document was obtained in some other manner (e.g. a data: URL typed in by the user, a Document created using the createDocument() API, etc) The origin is a globally unique identifier assigned when the Document is created. and this part: User agents must throw a SecurityError exception whenever any properties of a Document object are accessed by scripts whose effective script origin is not the same as the Document's effective script origin. means that if you createDocument() you then can't touch its properties. Which on the face of it is bogus. Similar issues with new Document() and DOMParser... XHR responseXML is OK, but only because XHR explicitly stamps the source origin on the responseXML document.
Uh yeah, that's weird. I should call out createDocument()-created docs separately. Anne, is the origin of a createDocument()-created Document something that DOM Core can define somehow so I can just point to that?
I could define that Document objects next to having a URL, content type, and encoding, they also have an origin which is a globally unique identifier when the document is created. Then for createDocument(), createHTMLDocument(), and the Document constructor I will say that the origin must be set to the global object's associated Document object's origin. It seems that will start blurring the lines between HTML and DOM, but I do not really see a better way (other than maybe adding hooks to all the places where a Document is constructed).
IMHO there are no lines between HTML and DOM. :-P
Okay, the tentative plan is to implement comment 3 and file a bug on HTML to align with DOM afterwards.
Defined concept-document-origin and used it. Used the entry script's origin to define the origin of document objects created through script. https://github.com/whatwg/dom/commit/922830c931d8b04d52e3482dfd9985cdcead43fe I'll update XHR to use this new concept and file a bug on HTML, but maybe bz can confirm that using the entry script's origin is correct?
Actually, using the entry script for origin stuff is almost never correct, I think. See thread starting with http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-November/038017.html and in particular http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-November/038023.html and http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-November/038030.html
And in particular, I think that each API that creates documents should explicitly define the origin that will be used for that document. For a DOMParser, say, it should be the origin of the Window the DOMParser is associated with or something like that.
So Window objects don't seem to have an origin per HTML. The global object's associated Document of course does. We could use that for new Document(), createDocument(), and createHTMLDocument(). Is that what Gecko does? Note that DOM just defines a default being a globally unique identifier, but also defines that for new Document(), createDocument(), and createHTMLDocument(), that is overridden (currently by the entry script's origin, but I guess we should change that to something else).
What Gecko does is use an alias to the origin and effective script origin of the Window (which is NOT the same as using the origin and effective script origin, note; I believe the alias thing is what we want). In gecko, the origin and effective script origin of a Window alias the origin and effective script origin of its associated document while it has a document. When it loses the document (unloaded, frame removed from DOM, document.open(), whatever) it continues to alias that no-longer-associated document's origin and effective script origin. If in the spec Windows never end up in a state where they have no associated document, then the spec can just talk about aliasing the associated document. > Note that DOM just defines a default being a globally unique identifier, but > also defines that for new Document(), createDocument(), and > createHTMLDocument(), that is overridden That makes sense to me. In all three of those cases we should, imo, alias the origin and effective script origin of the document involved (the associated document of the Window for the constructor, and the document the DOMImplementation came from for the other two).
I have done exactly that now. Search for "effective script origin" in http://dom.spec.whatwg.org/ to find all the instances. The catch all sets them to a globally unique identifer. new Document(), createDocument(), and createHTMLDocument(), use the alias concept as you described. I also filed bug 20463 to update HTML. https://github.com/whatwg/dom/commit/2f2cdf4a29b7ed299c38f60eb35ed98918a7f439 https://github.com/whatwg/dom/commit/0d20aee2ccccb9b9e2baacdca9b0ba82d398b948
Looks good, thanks!