[XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Hallvord Reiar Michaelsen Steen-3

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






Reply | Threaded
Open this post in threaded view
|

Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Anne van Kesteren-4
On Thu, Nov 22, 2012 at 12:34 PM, Hallvord Reiar Michaelsen Steen
<[hidden email]> 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 <var>-variables are scoped to the algorithm they
are used in. So you need to re-introduce <dfn
title=concept-XMLHttpRequest-document>document</dfn> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Hallvord Reiar Michaelsen Steen-3

> > "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 <var>-variables are scoped to the algorithm they
> are used in. So you need to re-introduce <dfn
> title=concept-XMLHttpRequest-document>document</dfn> 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






Reply | Threaded
Open this post in threaded view
|

Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Anne van Kesteren-4
On Thu, Nov 22, 2012 at 2:14 PM, Hallvord Reiar Michaelsen Steen
<[hidden email]> 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 <var>-variables are scoped to the algorithm they
>> are used in. So you need to re-introduce <dfn
>> title=concept-XMLHttpRequest-document>document</dfn> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Anne van Kesteren-4
On Thu, Nov 22, 2012 at 2:25 PM, Anne van Kesteren <[hidden email]> wrote:
> [...]

It seemed easier to just make the change:

https://github.com/whatwg/xhr/commit/67244d007243de427ffe8367ed0a7c49d40be199


--
http://annevankesteren.nl/