[Bug 23780] Check XMLHttpRequest and Notification don't break given the new script settings object stuff

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780

Jungkee Song <jungkees@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jungkees@gmail.com

--- Comment #9 from Jungkee Song <jungkees@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #8)
> (In reply to Anne from comment #7)
> > I will clean up the IDL when there is IDL syntax for document/worker
> > distinction.
> 
> Ok.
> 
> 
> > Until then document response entity body needs to check the environment I
> > think.
> 
> As far as I can tell, the current text can never be triggered.
> 

Setting xhr.responseType to "document" in a worker environment is simply
ignored and the value remains default, empty string. Hence, neither
xhr.response nor xhr.responseText does get through to "document response entity
body" algorithm. However, xhr.responseXML does do as it allows xhr.responseType
to be empty string though it finally returns null anyway. (Both Chrome and
Firefox return null with xhr.responseXML as specified; oddly, Chrome still
returns null with xhr.response whereas Firefox returns the text response body.)

If the intention is to disallow the "document" responseType in a worker context
at all, it seems safe to remove the environment checking condition in the
"document response entity body" algorithm. However, I wonder if there's any
reason "document" responseType should be disallowed in worker context. IMO, it
seems plausible to fetch a document in a worker context and post it to the main
document that created the worker?

> 
> > The "if x null, set x to y" is for when x is retrieved. x is set to null
> > during open() but cannot be retrieved until the request is completed. The
> > idea with using this type of wording is that x will have its value cached
> > until open() is invoked (again).
> 
> Personally I don't understand what it means, normatively. Either something
> has a value in which case retrieving it gives you that value, or, something
> has a getter, in which case retrieving it runs the algorithm and returns a
> value, but it doesn't itself have a value per se. I don't understand the
> concept of something both having a value and having an algorithm run when
> you call its getter.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 20 November 2013 06:57:03 UTC