- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 14 Apr 2008 16:44:53 -0700
- 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 UTC