Closed Bug 1720647 Opened 3 years ago Closed 2 years ago

Some sites stopped displaying text - roll20.net and forgottenrealms.fandom.com

Categories

(Core :: Layout: Text and Fonts, defect)

Firefox 90
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr91 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix

People

(Reporter: yoasif, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image roll20

From https://www.reddit.com/r/firefox/comments/okgnml/text_isnt_appearing_at_all_on_some_sites_in/

For some reason, certain sites completely stopped displaying text for me in Firefox. All of the other browsers I've tried work, but Firefox doesn't.

Can someone please tell me how to fix this? I'm not sure what the sites that are affected by this glitch have in common, but I do know that Roll20.net and forgottenrealms.fandom.com were affected.

User says 89 worked fine and disabling WebRender doesn't resolve the issue. User is on Windows 7.

Troubleshoot mode also works.

Setting gfx.e10s.font-list.shared to false resolves the issue.

Attached file about:support
Keywords: regression
Component: Graphics: WebRender → Graphics: Text
Component: Graphics: Text → Layout: Text and Fonts

(In reply to Asif Youssuff from comment #0)

Created attachment 9231293 [details]
roll20

From https://www.reddit.com/r/firefox/comments/okgnml/text_isnt_appearing_at_all_on_some_sites_in/

For some reason, certain sites completely stopped displaying text for me in Firefox. All of the other browsers I've tried work, but Firefox doesn't.

Can someone please tell me how to fix this? I'm not sure what the sites that are affected by this glitch have in common, but I do know that Roll20.net and forgottenrealms.fandom.com were affected.

User says 89 worked fine and disabling WebRender doesn't resolve the issue. User is on Windows 10.

According to the about:support in comment 1, the user is on Win7, and has not even installed Service Pack 1 ("Windows_NT 6.1 7600" is the original Win7 release build). This probably means they have an old and flaky DirectWrite. Maybe we should disable the shared font list on such old versions, given DW unreliability.

Hmm, actually it may not be the particular Windows version that's the issue. Rather, I think the affected user has some bad/broken/incompatible Helvetica fonts (maybe old bitmap or Type 1 versions?) installed, and those don't work via webrender. With the shared font-list disabled, we end up using Arial instead because of the default FontSubstitutes entries in Windows, but the new back-end doesn't forcibly apply those substitutions, it only uses them when the requested font is not found.

The affected sites mentioned here both explicitly call for Helvetica via font-family, so I suspect that's what is going on.

Setting gfx.windows-font-substitutes.always to true and restarting Firefox restores the old substitution behavior and would (probably) fix the issue for this user.

If we can determine what kind of fonts are involved here, we should try to exclude them from the font-list altogether so that this type of issue doesn't arise.

FTR, I tried installing a .pfb (type-1) version of Helvetica on my Windows (10) system, but that doesn't reproduce the problem; Firefox just doesn't even try to use it, afaict.

The user says something weird:

Helvetica doesn't appear in my windows font folder. However, when I look at the directory through a web browser, I can definitely see it's there. It appears that the system is trying to keep users from manipulating it directly.

Using a browser as a file browser reveals Helvetiva, but Windows Explorer doesn't (is what it sounds like).

Sigh. Yes - I don't know exactly what's going on, but I remember seeing this before... the Windows Explorer view of what appears to be the "font folder" is not a true view of what's in the directory, it is some kind of "virtual" folder of what Explorer thinks should show up. There can be font files present in the "real" directory (which can be seen by opening a Console window and looking with dir, for example) that Explorer hides, but they are in fact present and affect what applications see when they enumerate the available fonts.

I suspect that if the user were to remove the Helvetica font file(s) from c:\windows\fonts using a tool (not Explorer!) that operates directly on the filesystem, such as the command line (e.g. cd to the directory, copy the file(s) to another directory as a backup, then del them), and then restart Firefox, this would probably resolve the issue. But I'm still curious to know exactly what kind of Helvetica file(s) are involved here -- .ttf, .pfb, .fon, or what?

Severity: -- → S2

Do we know if this is still reproducible?

Given that we shipped gfx.e10s.font-list.shared enabled in v90 (which this bug was filed for) and we've left it on for another 8 releases (current release is version 98) without piles of duplicate missing-text bugs coming up, I wonder if this ended up being fixed? (Or maybe it's just extremely-rare?)

Regressed by: 1721824
See Also: → 1721824
Regressed by: 1694174
No longer regressed by: 1721824

(shot in the dark: jfkthame, do you know if bug 1716433 would have potentially fixed this [and sort-of-similar bug 1721824]?)

Flags: needinfo?(jfkthame)

(In reply to Daniel Holbert [:dholbert] from comment #9)

(shot in the dark: jfkthame, do you know if bug 1716433 would have potentially fixed this [and sort-of-similar bug 1721824]?)

er, never mind, that wouldn't have fixed it -- on closer inspection, I see that that bug's fix was uplifted to 90, so the affected users here would've already had that patch. So, that couldn't have fixed this.

Flags: needinfo?(jfkthame)

The patch in bug 1716433 didn't change default behavior; it would only have an effect if users explicitly set gfx.windows-font-substitutes.always to true (see comment 4), which might "fix" this by reverting to older font selection behavior (although there may still be an issue of some legacy fonts that, if selected, fail to render -- I don't think we ever established for sure whether that was going on here).

Set release status flags based on info from the regressing bug 1694174

Is this issue still reproducible?

Webcompat Priority: --- → ?
Flags: needinfo?(yoasif)

I've asked the original poster on Reddit via DM to see if this still reproduces for them.

OP sent me a message back saying that it works for them. Closing as such.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(yoasif)
Resolution: --- → WORKSFORME
Webcompat Priority: ? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: