1170297 - querySelector should only throw warnings for unknown selectors

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Brenton]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

Steps to reproduce:

document.querySelectorAll(":autofill")


Actual results:

SyntaxError: An invalid or illegal string was specified


Expected results:

An empty Array should have been returned.


When sites begin using CSS4 selectors[1], they will start breaking in versions of Firefox that don't support those selectors.  To better support graceful degradation, unrecognized selectors should only throw warnings (never errors).

Otherwise, these are the gymnastics you'll have to go through to avoid such issues:

    var autofilled = false;

    // Must wrap these tests in a `try` because the browser will throw if it
    // doesn't recognize a selector
    try {
      autofilled = Boolean(node.parentNode.querySelector(":autofill"));

    } catch (error) {                                      
      try {
        autofilled = Boolean(node.parentNode.querySelector(":-webkit-autofill"));

      } catch (error) {                                      
        try {
          autofilled = Boolean(node.parentNode.querySelector(":-moz-autofill"));

        } catch (error) {}
      }
    }  

when the test should simply be:

    var autofilled = Boolean(
      node.parentNode.querySelector(":autofill, :-webkit-autofill, :-moz-autofill")
    );

[1] https://wiki.csswg.org/spec/css4-ui#more-selectors


Here's the related Chromium bug:

https://crbug.com/495243

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://www.w3.org/TR/selectors-api/#queryselector
http://www.w3.org/TR/selectors-api/#parse-a-selector
and
https://dom.spec.whatwg.org/#dom-parentnode-queryselectorselectors
https://dom.spec.whatwg.org/#scope_match-a-selectors-string
are both clear that a syntax error should be thrown for invalid selectors.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep.  The spec very explicitly calls for this behavior.

The reason for that is that it allows the caller to tell apart "no elements matched the selector" and "I have no idea how to match this selector" and in the latter case to fall back to some other method of getting the desired result set.

This does cause problems with prefixed selectors, but note that we have no plans to introduce new such selectors (e.g. no plans for a :-moz-autofill).

Comment 3

[Brenton]

I understand that I need to take it up with WHATWG, but that part of the spec seems insane.  I know how careful WHATWG is generally about not-breaking the Web, and as it stands, this is guaranteed to.  Eventually, a new selector is going to be added and sites are going to start using it.  (There are 14 new selectors in the CSS4 proposal I linked.  I'd be surprised if in the entire future of the Web, nobody ever adds a new selector.)

Somebody is going to use `querySelector(":autofill")` without knowing about that corner of the spec, and their site is going to break in versions of Firefox that don't yet know about :autofill.

Imagine how impossible HTML 5 would have been if the JS engine threw an error when it saw a tag it didn't recognize.

Comment 4

[Boris Zbarsky [:bzbarsky]]

People use querySelector with unupported selectors all the time right now.  They just try-catch around it and fall back to an alternate implementation if it's unsupported.

And in particular, changing the behavior of querySelector at this point would break every single library (e.g. jQuery) that uses it, since they rely on it throwing for their made-up custom selectors (like :visible) so they can call back to their own implementation.

I agree that it would have been better to have an API here that didn't use exceptions to signal "not supported", and if we were having this conversation when the API was introduced, about 10 years ago, I would agree with you.  But at this point changing the behavior would totally break sites, in a very non-hypothetical way.

> Imagine how impossible HTML 5 would have been if the JS engine threw an error when it
> saw a tag it didn't recognize.

If you could catch the exception and handle, and if it only happened in APIs that had been doing that for a decade and that everyone knew did that?  It wouldn't have been impossible at all.