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
