Standard fonts list doesn't contain the localized name
Categories
(Core :: Privacy: Anti-Tracking, defect, P2)
Tracking
()
People
(Reporter: 6k64x4ma, Assigned: jfkthame)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [fpp:m5])
Attachments
(2 files)
201 bytes,
text/html
|
Details | |
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
pascalc
:
approval-mozilla-release+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0
Steps to reproduce:
- Load the attached file in the private window on Windows.
Actual results:
- Serif font is used for second div because the localized name is not recognized by font visibility restrictions.
Expected results:
- The Latin name and the localized name should be treated equally.
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Jonathan, is there a way for the font visibility check to match the localized font name with the font name in the list?
Comment 2•1 year ago
•
|
||
This bug is seen by more users with the fix for bug 1846224.
For example, if a JA user with ETP set to Strict sets font.name.sans-serif.ja to "BIZ UDPゴシック" through about:preferences, which is the localized font name for the "BIZ UDPGothic" font, "BIZ UDPゴシック" will not match and will use Meiryo font which is set to font.name-list.sans-serif.en for fallback.
Assignee | ||
Comment 3•1 year ago
|
||
(In reply to Tim Huang[:timhuang] from comment #1)
Jonathan, is there a way for the font visibility check to match the localized font name with the font name in the list?
Yeah, I think we should make it so that the same visibility level is used for all localized names of a font family. This looks reasonably straightforward to implement.
Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 5•1 year ago
|
||
[Tracking Requested - why for this release]:
- Significant visual regression occurs on web pages that use localized font names in the font-fmily CSS property.
- Significant visual regression occurs on web pages when localized font names and strict ETP are set at about:preference.
Updated•1 year ago
|
Comment 7•1 year ago
|
||
Doesn't this also affect 118? Bug 1849903 landed in that version.
Updated•1 year ago
|
Comment 9•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Assignee | ||
Comment 10•1 year ago
|
||
Comment on attachment 9353736 [details]
Bug 1850672 - Standard platform font-visibility level should be applied to localized names of the family. r=#layout-reviewers
Beta/Release Uplift Approval Request
- User impact if declined: Potential for wrong fonts used in private-browsing windows due to anti-fingerprinting setting - primarily affecting CJK content.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: STR in comment 0
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Minor change during font-list initialization, to ensure all (localized) names of a font are classed as equivalent for lookup
- String changes made/needed:
- Is Android affected?: No
Assignee | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Set release status flags based on info from the regressing bug 1849903
Comment 12•1 year ago
|
||
Comment on attachment 9353736 [details]
Bug 1850672 - Standard platform font-visibility level should be applied to localized names of the family. r=#layout-reviewers
Approved for 119.0b3
Comment 13•1 year ago
|
||
uplift |
Updated•1 year ago
|
Updated•1 year ago
|
Comment 14•1 year ago
|
||
Reproduced this issue on an affected Nightly build from 2023-08-30, on Win 10.
Verified as fixed on latest nightly 120.0a1 (20230928215127) and Firefox 119.0b3 (treeherder build 20230927183607) on Win 10, Ubuntu 20.04 and macOS 10.15.
Comment 15•1 year ago
|
||
Jonathan, is this a good candidate for uplifting in our planned dot release? Thanks
Assignee | ||
Comment 16•1 year ago
|
||
I don't have a strong opinion one way or the other. On the one hand, I believe the patch has minimal risk, and it will improve the experience for affected users/sites; but on the other hand the "breakage" is cosmetic (wrong/less-desirable font being used) rather than drastic (content unusable).
I guess Japanese & Chinese users might appreciate it being uplifted; they're probably the main communities affected (though by no means all users, as it's only relevant when anti-fingerprinting settings are made stricter, as in private browsing).
Assignee | ||
Comment 17•1 year ago
|
||
Comment on attachment 9353736 [details]
Bug 1850672 - Standard platform font-visibility level should be applied to localized names of the family. r=#layout-reviewers
Beta/Release Uplift Approval Request
- User impact if declined: Some users (especially CJK) may get wrong/undesired fonts when strict anti-fingerprinting is in force.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Patch just changes visibility annotations on localized font names; otherwise, no functional changes.
- String changes made/needed:
- Is Android affected?: No
Comment 19•1 year ago
|
||
Comment on attachment 9353736 [details]
Bug 1850672 - Standard platform font-visibility level should be applied to localized names of the family. r=#layout-reviewers
Approved for our next 118 dot release, thanks.
Comment 20•1 year ago
|
||
uplift |
Comment 21•1 year ago
|
||
bugherder uplift |
Updated•1 year ago
|
Comment 22•1 year ago
|
||
Verified as fixed on Firefox 118.0.2 (20231009140911) on Windows 10, Ubuntu 20.04 and macOS 10.15.
Description
•