Bug 239552 - foo|bar with @namespace foo "*" erroneously treated as *|bar
Summary: foo|bar with @namespace foo "*" erroneously treated as *|bar
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Minor
Assignee: Nobody
URL: https://bucket.daz.cat/work/igalia/bu...
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2022-04-20 10:54 PDT by Delan Azabani
Modified: 2024-01-19 05:41 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Delan Azabani 2022-04-20 10:54:00 PDT
Test page: https://bucket.daz.cat/work/igalia/bugs/0.xhtml

The right hand side of a @namespace rule can be any string, with only the empty string having the special meaning of “null namespace or lack of a namespace” [css-namespaces-3]. The rule gives the namespace a nickname that can be used in foo|bar selectors, or when there is no nickname, it restricts the namespace of unqualified type selectors [selectors-4].

*|bar forces the type selector to match any namespace (or none at all), but we treat foo|bar and bar the same way when there is @namespace foo "*" or @namespace "*" respectively. This is unlikely to be a real problem in practice, because XML only allows namespaces with a valid absolute URI, but it’s still incorrect.

The root cause seems to be that SelectorChecker and friends check if QualifiedName::namespaceURI() is starAtom(), which comes from CSSSelectorParser::determineNamespace, which returns starAtom() both when the prefix is star and when the namespace “URI” is star.
Comment 1 Radar WebKit Bug Importer 2022-04-27 10:54:12 PDT
<rdar://problem/92408313>
Comment 2 Ahmad Saleem 2023-09-23 16:02:38 PDT
I am still able to reproduce this bug in Safari Technology Preview 179 and also in Chrome Canary 119 while Firefox Nightly 119 works fine and don't show 'FAIL' text.