Closed Bug 1808783 Opened 1 year ago Closed 1 year ago

font.name entries still showing up in Preference Sanitization

Categories

(Core :: Preferences: Backend, defect)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tjr, Assigned: tjr)

References

(Blocks 1 open bug)

Details

I'm not sure why, but 108 release is still reporting usages of preferences like font.name.monospace.tr and font.name.fantasy.x-western in the content process even though we should be allowlisting those. Relatively small number of users, but given the disparate events I think this is a generic problem.

I fiddled with the default font preferences (which I know set the preferences) and then went online to various websites and font demos, but I could not reproduce the issue. But I also don't know what causes those preferences to be read.

:jfkthame - would you be able to give me concrete steps to visit a specific page and change a specific setting and then observe the change in the page? Setting fission.enforceBlocklistedPrefsInSubprocesses should make the content process crash when that happens and confirm we're reproducing things correctly. If I can observe the crash then I should be able to debug why the allowlisting isn't working...

Flags: needinfo?(jfkthame)

(Sorry for the late reply...)

Probably the most straightforward way to observe these prefs being used is to load a plain-text document such as https://www.unicode.org/Public/UCD/latest/ucd/ReadMe.txt, which will render with the default monospace font; then go to Preferences (the Fonts / Advanced... subdialog) and try changing the Monospace font for Latin to something obviously different. After clicking OK on the Advanced subdialog, the new pref value should be stored (you can see it as font.name.monospace.x-western in about:config), and switching back to the tab of the plain-text file should show the new font being used.

FWIW, though, I tried setting fission.enforceBlocklistedPrefsInSubprocesses to true and then doing a font-pref change like this (in Nightly on macOS), and nothing crashed; the changed font-pref setting is still successfully used by the content process rendering the text file. (Changing the monospace font from the default of Menlo to something entirely different like Apple Chancery makes it really obvious.) So I'm not sure I am understanding the scenario here properly...? Is there something else I need to do in order to exercise the crash path?

Flags: needinfo?(jfkthame) → needinfo?(tom)

No. I can't reproduce it either =/

I did some more datamining about the affected people. It's just 22 users on release reporting this data. A wide range of countries/locales although 8 from Poland. 19 Windows, 3 Linux, no Mac. Windows 6.1 and 10. 5 is the most number of them that share an extension, excluding the Mozilla built-in ones.

I can't really make much sense of the rest of the raw telemetry tables, but nothing is jumping out to me as potentially correlating while just looking at gigantic raw JSON blobs.

I'm going to leave this open for now, but our next steps for this lie beyond this bug I think.

Flags: needinfo?(tom)

The severity field is not set for this bug.
:KrisWright, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(kwright)
Severity: -- → S4
Flags: needinfo?(kwright)
Whiteboard: [sp3]

We are no longer seeing telemetry for this.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.