RESOLVED CONFIGURATION CHANGED 89682
Throw SYNTAX_ERR instead of NAMESPACE_ERR from querySelector(All)
https://bugs.webkit.org/show_bug.cgi?id=89682
Summary Throw SYNTAX_ERR instead of NAMESPACE_ERR from querySelector(All)
Pablo Flouret
Reported 2012-06-21 11:37:45 PDT
The spec now says: [[ If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception ]] http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces Thread here: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1225.html Mozilla already changed it: https://bugzilla.mozilla.org/show_bug.cgi?id=766798
Attachments
Patch (10.23 KB, patch)
2012-06-21 12:02 PDT, Pablo Flouret
no flags
Rebased patch (8.36 KB, patch)
2012-06-21 14:05 PDT, Pablo Flouret
eric: review-
Pablo Flouret
Comment 1 2012-06-21 11:50:47 PDT
It seems i linked to the email with the decision, the first email in the thread shows the problem: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1207.html Basically, in some cases where both SyntaxError and NamespaceErr applied, webkit found the namespace error first, whereas other browsers found the syntax error first, leading to different exceptions being thrown.
Pablo Flouret
Comment 2 2012-06-21 12:02:49 PDT
Pablo Flouret
Comment 3 2012-06-21 12:03:53 PDT
(In reply to comment #2) > Created an attachment (id=148855) [details] > Patch I modified Element::webkitMatchesSelector as well, let me know if it's better to keep that one as is.
Pablo Flouret
Comment 4 2012-06-21 14:05:09 PDT
Created attachment 148884 [details] Rebased patch
Erik Arvidsson
Comment 5 2012-06-21 15:13:47 PDT
Comment on attachment 148884 [details] Rebased patch View in context: https://bugs.webkit.org/attachment.cgi?id=148884&action=review Looks good to me but I'm not a reviewer. > Source/WebCore/ChangeLog:14 > + [[ > + If the group of selectors include namespace prefixes that need to be > + resolved, the implementation must raise a SYNTAX_ERR exception > + ]] I'm not sure we should use trac wiki markup here?
Ryosuke Niwa
Comment 6 2012-06-21 15:18:41 PDT
Comment on attachment 148884 [details] Rebased patch View in context: https://bugs.webkit.org/attachment.cgi?id=148884&action=review >> Source/WebCore/ChangeLog:14 >> + ]] > > I'm not sure we should use trac wiki markup here? Yeah, we don't normally do that. > Source/WebCore/ChangeLog:20 > + Thread here: > + http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1225.html > + Are you sure the spec is stable enough for us to change the behavior? I would not want us end up flip-flopping between different behaviors.
Pablo Flouret
Comment 7 2012-06-21 15:36:22 PDT
(In reply to comment #6) > (From update of attachment 148884 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=148884&action=review > > >> Source/WebCore/ChangeLog:14 > >> + ]] > > > > I'm not sure we should use trac wiki markup here? > > Yeah, we don't normally do that. It's sometimes used to refer to spec excerpts, i didn't realize it was wiki markup as well. I can use quotes if it'll bring trouble. > > Source/WebCore/ChangeLog:20 > > + Thread here: > > + http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1225.html > > + > > Are you sure the spec is stable enough for us to change the behavior? > I would not want us end up flip-flopping between different behaviors. Mozilla made the change already, and multiple Opera people are the ones that suggested this change. Lachy also argues that the distinction is probably not very useful anymore (and that at least Sizzle doesn't seem to care about it): http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1215.html The spec is going to last call soon, and moving straight to PR if nothing comes up, if i understood correctly. I don't think it's very urgent, so it's probably ok to wait for a while before landing if you prefer.
Eric Seidel (no email)
Comment 8 2012-08-12 03:56:23 PDT
Comment on attachment 148884 [details] Rebased patch Looks like reviewers are askign for another round.
Pablo Flouret
Comment 9 2013-02-05 14:49:28 PST
Anne van Kesteren
Comment 10 2023-12-18 04:26:21 PST
Document::selectorQueryForString() appears to handle this correctly.
Note You need to log in before you can comment on or make changes to this bug.