20390 2012-12-14 16:02:45 +0000 The origin of documents not in a browsing context is wrong in the spec 2012-12-20 17:36:42 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#sandboxOrigin P3 normal --- 1 contributor annevk annevk bobbyholley bzbarsky ian mike Ms2ger www-dom public-webapps-bugzilla oldest_to_newest 80184 0 contributor 2012-12-14 16:02:45 +0000 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 80185 1 bzbarsky 2012-12-14 16:06:25 +0000 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. 80223 2 ian 2012-12-14 23:24:58 +0000 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? 80234 3 annevk 2012-12-15 10:18:47 +0000 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). 80371 4 ian 2012-12-18 19:19:10 +0000 IMHO there are no lines between HTML and DOM. :-P 80373 5 annevk 2012-12-18 19:52:47 +0000 Okay, the tentative plan is to implement comment 3 and file a bug on HTML to align with DOM afterwards. 80402 6 annevk 2012-12-19 12:44:30 +0000 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? 80416 7 bzbarsky 2012-12-19 17:45:41 +0000 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 80417 8 bzbarsky 2012-12-19 17:46:39 +0000 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. 80421 9 annevk 2012-12-19 18:20:21 +0000 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). 80422 10 bzbarsky 2012-12-19 19:38:58 +0000 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). 80445 11 annevk 2012-12-20 16:11:53 +0000 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 80449 12 bzbarsky 2012-12-20 17:36:42 +0000 Looks good, thanks!