W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Re: [selectors-api] NSResolver moving nodes between documents

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 14 Apr 2008 16:44:53 -0700
Message-ID: <4803EC75.8010605@sicking.cc>
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Web APIs WG <public-webapi@w3.org>

Jonas Sicking wrote:
> 
> Boris Zbarsky wrote:
>>
>> Jonas Sicking wrote:
>>> 1. Parse selector
>>> 2. Walk the DOM and create result using parsed selector.
>>
>> That seems like the obvious approach.
>>
>>> This way it is ok if the NSResolver mutates the DOM in any fashion. 
>>> The result returned from the function will simply be based on what 
>>> the DOM looks like after step 1 is done executing.
>>
>> There's one security consideration here, though:  Say at the end of 
>> the mutation the script that called querySelector is no longer 
>> same-origin with the node that the method was called on.  What should 
>> happen?  Immediate exception?  Return the nodes but not allow the 
>> caller to actually access them?  Something else?
>>
>> My gut feeling is that "immediate exception" is the right thing to be 
>> doing...
> 
> So this generally can't happen, except through implementation specific 
> quirks, no? I.e. a page can't create an NSResolver mutates nodes to the 
> point where it no longer has access to the page.

Ugh, sorry, this should say:
So this generally can't happen, except through implementation specific 
quirks, no? I.e. a page can't create an NSResolver which mutates nodes 
to the point where the page no longer has access to the nodes.

> So since this would be implementation specific behavior, possibly due to 
> security bugs, I think it's fine if the solution is also implementation 
> specific and we wouldn't need to say anything in the spec.
> 
> / Jonas
> 
Received on Monday, 14 April 2008 23:47:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 April 2008 23:47:30 GMT