www.davy.ie menus not appearing

[ZFR77]

https://www.davy.ie/

If you click on the hamburger menu top right, then click on the padlock (login), a menu is supposed to appear with login options. The "Search" and "Call us" buttons do not work either.

Code: Select all

SyntaxError: 'a[target="_blank"]:not([class*="modal-video"]' is not a valid selector  
www.davy.ie:1996
JQMIGRATE: Migrate is installed, version 3.4.1  
scripts.js:1:91646
SyntaxError: 'a[target="_blank"]:not([class*="modal-video"]' is not a valid selector  
scripts.js:1

[vannilla]

This is a real site error since it lacks the closing parentheses at the end.
It should be a[target="_blank"]:not([class*="modal-video"]).

[ZFR77]

This is a real site error since it lacks the closing parentheses at the end.
It should be a[target="_blank"]:not([class*="modal-video"]).

hmmm... When I try on Firefox though, the menu does work, and no errors appear on console.

[Moonchild]

This is a real site error since it lacks the closing parentheses at the end.
It should be a[target="_blank"]:not([class*="modal-video"]).

hmmm... When I try on Firefox though, the menu does work, and no errors appear on console.

Vannilla is correct. Line 1996 of the html has:

Code: Select all

document.querySelectorAll('a[target="_blank"]:not([class*="modal-video"]')

And that is an invalid selector. Firefox should also error out on that. If it doesn't, then that's not handling JS queryselector errors properly! i.e. we're doing things right and Firefox isn't, in that case.
I'm assuming this exact same error is repeated in scripts.js (but I didn't feel like finding it in the minified blob)

[ZFR77]

Thanks for checking.

I'll email their webmaster and inform him about this.

[back2themoon]

Is it safe to assume there's some kind of threshold (or secret understanding, or relaxed spec allow-list or whatever) below which "major browsers" allow errors like this to "pass"?

Is there a pattern somewhere, or is it just random? Because if there is, I guess it could solve several Pale Moon web compatibility issues, right? You'd know where to allow non-fully-compliant specs.

[Moonchild]

Is it safe to assume there's some kind of threshold (or secret understanding, or relaxed spec allow-list or whatever) below which "major browsers" allow errors like this to "pass"?

Both Firefox and Chrome have some level of "connect at all costs" and "making assumptions in case of errors" instead of sticking to strictness/throwing errors as they should. It's really bad practice because it masks errors and doesn't alert webmasters/admins of their mistakes.

[adoxa]

Until they fix it their end here's a Modify HTTP Response workaround in the meantime (for davy, it doesn't seem to be needed for mydavy).

Code: Select all

[["www.davy.ie",["/^[^.]*$|scripts.js/",["o\"]'","o\"])'"]]]]

[FranklinDM]

And that is an invalid selector. Firefox should also error out on that. If it doesn't, then that's not handling JS queryselector errors properly! i.e. we're doing things right and Firefox isn't, in that case.

Off-topic:
I'm not sure if you'd consider this a regression, but this seems to be a side-effect of the approach I took in Issue #2137 (UXP). querySelectorAll is inconsistent in what it considers as invalid syntax for pseudo-classes. For instance, :nth-of-type(1 is considered an invalid selector, but :not(a is considered valid (before the mentioned issue landed; legacy behavior is currently controlled by the layout.css.legacy-negation-pseudo.enabled pref and can be toggled). However, latest Firefox seems to have relaxed its behavior and considers both of these as valid selectors.

[Moonchild]

Off-topic:

but this seems to be a side-effect of the approach I took in Issue #2137 (UXP). querySelectorAll is inconsistent in what it considers as invalid syntax for pseudo-classes. For instance, :nth-type(1 is considered an invalid selector, but :not(a is considered valid (before the mentioned issue landed; legacy behavior is currently controlled by the layout.css.legacy-negation-pseudo.enabled pref and can be toggled). However, latest Firefox seems to have relaxed its behavior and considers both of these as valid selectors.

I did some research and even Firefox's own MDN pages state that "This string must be a valid CSS selector string; if it isn't, a SyntaxError exception is thrown.". The standard agrees.
So I looked into the standards document what is a valid selector, and there is zero mention of pseudo-class function syntaxes (which :not() is) making exceptions for missing closing parentheses.
The standard explicitly states, drilling deeper, that a closing parenthesis is not optional for a function type pseudo class:
https://drafts.csswg.org/selectors-4/#grammar

Image1.png

"<function-token>s, which are written as the function name followed by a ( character, like translate(. "
The above requires that it be :not(selector here) with no exceptions (or the closing paranthesis in grammar would have been marked as optional; it isn't)...
I'm not sure why Firefox relaxed this; the "paren-less" syntax to me seems just incorrect and shouldn't be parsed. Quite possible they just decided to "parse at all costs", possibly because Chrome accepts it contrary to the standard?

This is not new syntax. CSS selectors3 from 2018 also mandates the ')', so does the version from 2011...

Let me know if I'm missing something?

[ZFR77]

Until they fix it their end here's a Modify HTTP Response workaround in the meantime (for davy, it doesn't seem to be needed for mydavy).

Code: Select all

[["www.davy.ie",["/^[^.]*$|scripts.js/",["o\"]'","o\"])'"]]]]

Thank you, adoxa. That worked.

[FranklinDM]

Off-topic:

So I looked into the standards document what is a valid selector, and there is zero mention of pseudo-class function syntaxes (which :not() is) making exceptions for missing closing parentheses.
...
I'm not sure why Firefox relaxed this; the "paren-less" syntax to me seems just incorrect and shouldn't be parsed. Quite possible they just decided to "parse at all costs", possibly because Chrome accepts it contrary to the standard?

Yeah, I reached a similar conclusion back then. Just more accommodation for sloppy coding, I guess.

[jobbautista9]

Apparently Mozilla knew about this 12 years ago and decided not to fix it: bug #815662

[Moonchild]

Apparently Mozilla knew about this 12 years ago and decided not to fix it: bug #815662

They are wrong because that is talking about declaration blocks (i.e. the { } declaration blocks), not function definitions (using ( ) parentheses). How did nobody catch that?
I looked again this time in the specific syntax document that is currently the latest active standards track document, that does mention <EOF> explicitly, and that should be a parse error, it should definitely still throw an error in the console at the very least and never silently accept it. Parse errors are normally just warnings (with the affected declaration ignored, as we do if an unknown keyword is found for example), and either way it would not be parsed as something valid there according to the standards, even if the function is returned. That means it should never be accepted as valid or something functional, but it seems that it just wholly ignored.
Once more the function pseudo-class does not allow the closing parenthesis to be omitted and explicitly says to throw a syntax error, which I think should clearly override any parse errors that have lower severity.

EDIT: Maybe it would serve for someone to file a new bug on this because I'm not sure the older standards docs made that distinction.

[FranklinDM]

I'm not sure if I understood this correctly, but it seems like this bullet from 12.6 (which links back to the old spec mentioned in the bug) would be their supposed justification for making the unclosed pseudo-class function "valid" in the current spec, given that the value passed to querySelector/All does pass through the tokenizer:

Apply the EOF error handling rule in the tokenizer and emit normal <string-token> and <url-token> rather than BAD_STRING or BAD_URI on EOF.

[Moonchild]

I don't think so. A function is neither a string nor a URI, after all? (and even if a "string" then it should still be syntactically correct when passed back up from the tokenizer, right?)
I did notice someone quietly changed the syntax document to suddenly no longer have the parse error on EOF for a function, which was explicitly added in an issue on W3C before, so I opened a new issue on their document for that.

[Goodydino]

This is a real site error since it lacks the closing parentheses at the end.
It should be a[target="_blank"]:not([class*="modal-video"]).

hmmm... When I try on Firefox though, the menu does work, and no errors appear on console.

Interesting. I tried that with Waterfox and LibreWolf and neither works with that menu. Both are derived from modern Firefox.