Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
On Thu, Nov 22, 2012 at 2:25 PM, Anne van Kesteren wrote: > [...] It seemed easier to just make the change: https://github.com/whatwg/xhr/commit/67244d007243de427ffe8367ed0a7c49d40be199 -- http://annevankesteren.nl/
Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
On Thu, Nov 22, 2012 at 2:14 PM, Hallvord Reiar Michaelsen Steen wrote: >> You'd also need to check the JavaScript global environment. > > Thanks for responding. How? Just like the spec does now? >> What I mean is that -variables are scoped to the algorithm they >> are used in. So you need to re-introduce > title=concept-XMLHttpRequest-document>document or some such. > > Ah, OK. We already have an instance property named "referrer source", which > is a somewhat obscure name but does reference the document. Can we just > re-name "referrer source" => "associated document" or something, and set it > in constructor, then use it for the "not fully active" check etc in open() ? No, see below. > (Naming it "referrer source" re-uses terminology from CORS or Workers? I > believe it will always refer to a document - in "web worker mode" the > document associated with the script - and we can say "use associated document > as *override referrer source* when referencing CORS algorithm. IMO this is > easier to understand in the context of this spec.) Referrer source is from HTML and can be a URL. I prefer to keep that name consistent throughout all specifications. -- http://annevankesteren.nl/
Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
> > "Let document be the document associated with the global object of the > > XMLHttpRequest interface object." > > You'd also need to check the JavaScript global environment. Thanks for responding. How? > What I mean is that -variables are scoped to the algorithm they > are used in. So you need to re-introduce title=concept-XMLHttpRequest-document>document or some such. Ah, OK. We already have an instance property named "referrer source", which is a somewhat obscure name but does reference the document. Can we just re-name "referrer source" => "associated document" or something, and set it in constructor, then use it for the "not fully active" check etc in open() ? (Naming it "referrer source" re-uses terminology from CORS or Workers? I believe it will always refer to a document - in "web worker mode" the document associated with the script - and we can say "use associated document as *override referrer source* when referencing CORS algorithm. IMO this is easier to understand in the context of this spec.) > > (Just for the record, the corner cases we need to consider here include > > stuff like > > var xhr=new iframe.contentWindow.XMLHttpRequest() > > This is not a corner case in actual content. If it was we would made > it work the same way it does in Workers. The precise definition of "corner case" is a hair I have no intention of helping you split :-) -- Hallvord R. M. Steen Core tester, Opera Software
Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
On Thu, Nov 22, 2012 at 12:34 PM, Hallvord Reiar Michaelsen Steen wrote: > This is quite convoluted, but precise. The last "object" could perhaps be > "instance" to make it clearer? However, my proposal is to move this text to > the constructor section (4.2 Constructors), for example as a new 3rd step in > the first numbered list, and simplify it to read: > > "Let document be the document associated with the global object of the > XMLHttpRequest interface object." You'd also need to check the JavaScript global environment. > Anne responded: > >> You cannot just move it to the constructor without introducing some >> other XHR-wide variable. > > Sorry Anne, you could probably edit the XHR spec asleep... What I mean is that -variables are scoped to the algorithm they are used in. So you need to re-introduce document or some such. >>> I also believe the implementation difference can not be observed from JS. >> >> Not if you make the same requirements, no... > > I believe both the old text and the proposal would end up with *document* > referencing the same document, even in corner cases. If I'm missing something > please explain, thanks. My comment meant to indicate that if you move requirements around you will not have a difference. However, if you remove requirements as done in http://dvcs.w3.org/hg/xhr/rev/fe301b5c5917 (later reverted) you will. > (Just for the record, the corner cases we need to consider here include stuff > like > var xhr=new iframe.contentWindow.XMLHttpRequest() This is not a corner case in actual content. If it was we would made it work the same way it does in Workers. -- http://annevankesteren.nl/
[XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
I'm taking a back-channel discussion on-list per Anne's suggestion. We are trying to clarify some text in section 4.6.1, "The open() method" which is meant to describe how an XMLHttpRequest instance is associated with a specific document. (This association is important for origin checks, security etc.) The current text says: "Let *document* be the document associated with the global object for which the XMLHttpRequest interface object was created from which this XMLHttpRequest object was created." This is quite convoluted, but precise. The last "object" could perhaps be "instance" to make it clearer? However, my proposal is to move this text to the constructor section (4.2 Constructors), for example as a new 3rd step in the first numbered list, and simplify it to read: "Let document be the document associated with the global object of the XMLHttpRequest interface object." Anne responded: > You cannot just move it to the constructor without introducing some > other XHR-wide variable. Sorry Anne, you could probably edit the XHR spec asleep but however obvious it may be to you, I need some more details here ;). We're defining an "instance variable" called *document* and discussing whether we should define it when the instance is constructed or when the open() method is called. I don't understand what state we would need another XHR-wide variable to track if we move it. As far as I can tell, nothing can be done after constructing an instance but before calling open() that would require *document* to be unset, or require knowing if it is set or not. > But yes, there's an open issue about whether > we should maybe do that. I'd prefer discussion on a public list. Hereby implemented, Sir ;-) > > I also believe the implementation difference can not be observed from JS. > > Not if you make the same requirements, no... I believe both the old text and the proposal would end up with *document* referencing the same document, even in corner cases. If I'm missing something please explain, thanks. (Just for the record, the corner cases we need to consider here include stuff like var xhr=new iframe.contentWindow.XMLHttpRequest() XMLHttpRequest.prototype.open.call(xhr, ...) iframe.contentWindow.XMLHttpRequest.prototype.open.call( xhr=new XMLHttpRequest, ... ) and possibly other weirdness. The spec needs to dictate a consistent and compatible way to reference the correct document..) -- Hallvord R. M. Steen Core tester, Opera Software
