CSS :lang selectors never match against languages with private use tags
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | wontfix |
firefox116 | --- | wontfix |
firefox117 | --- | wontfix |
firefox118 | --- | fixed |
People
(Reporter: uruwi, Assigned: jfkthame)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0
Steps to reproduce:
I opened the attached langtest.html file in Firefox.
Actual results:
The word ‘har’ is not in red.
Expected results:
The word ‘har’ should be shown in red, because the only CSS rule in this document has a selector of ‘:lang(art-x-v3-arx0as)’. This should match any element with a language of ‘art-x-v3-arx0as’ because ‘art-x-v3-arx0as’ is a valid BCP-47 language tag (albeit a private use one).
Replacing ‘art-x-v3-arx0as’ with a language code without a private use tag such as ‘art’ produces the expected behavior, although ‘:lang(art)’ does not match against elements with a language of ‘art-x-v3-arx0as’.
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
Can repro this behaviour in Nightly. Chrome shows "har" in red.
Comment 3•1 year ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=23fa52107ed38f5c5f06ebed5dce4bc4287143b5&tochange=f1dcf41730702a8752420abf555b734464fdf1b8
Updated•1 year ago
|
Comment 4•1 year ago
|
||
:jfkthame, since you are the author of the regressor, bug 1121792, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 5•1 year ago
|
||
Interestingly, Safari likewise doesn't match the :lang() selector in the testcase from comment 0, although Chrome does.
In Gecko, this fails because the lang attribute and the :lang() selector's argument are passed to intl::ffi::unic_langid_new() here, in order to parse them and then perform matching; but unic_langid_new() doesn't handle private subtags, and so rejects them as "invalid".
For the time being I think we can consider dealing with this in nsStyleUtil for the specific case of :lang()-selector matching, by checking for the presence of private subtags (delimited by -x-
) and adding custom handling for them. In the longer term, we may want to extend unic_langid_new and the underlying LanguageIdentifier (see https://searchfox.org/mozilla-central/source/third_party/rust/icu_locid/src/langid.rs) to handle private subtags in some way.
The behavior I propose to try here is that if the :lang() selector includes private subtags, then it will only match elements where the lang attribute has the same subtags; but the presence of private subtags in an element's lang attribute will not prevent it matching a selector that has the same (standard) language subtags but doesn't include private subtags. So :lang(en-x-private)
would NOT match elements with lang="en"
or lang="en-x-other"
, but a simple :lang(en)
WOULD still match elements with lang="en-x-foobar"
.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 6•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 7•1 year ago
|
||
Updated•1 year ago
|
Comment 10•1 year ago
|
||
Backed out for causing reftest failures in unicode-lang.html
- Backout link
- Push with failures
- Failure Log
- Failure line: REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/unicode/unicode-lang.html == layout/reftests/unicode/unicode-ref.html | image comparison, max difference: 255, number of differing pixels: 167
Assignee | ||
Comment 11•1 year ago
|
||
Ah, right - we're missing a return false
in the case where the tag fails to parse, but there isn't a private subtag to be stripped for a re-try.
Comment 12•1 year ago
|
||
Comment 14•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/fdca3f17a750
https://hg.mozilla.org/mozilla-central/rev/1cafd355bbcf
Comment 16•1 year ago
|
||
The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox117
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 17•1 year ago
|
||
I don't think this warrants uplift; it can just ride the 118 train.
Updated•1 year ago
|
Description
•