Closed Bug 1759891 Opened 2 years ago Closed 2 years ago

Seeing funny characters in Google Slides


(Core :: Graphics: Text, defect, P1)




100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- unaffected
firefox99 --- unaffected
firefox100 + verified


(Reporter: mchan, Assigned: lsalzman)




(Keywords: regression)


(10 files)

Seeing funny characters in Google Slides presenter mode on Zoom (also when not on presenter mode)
I am using Firefox nightly (updated)

Could you confirm what platform and OS version you're on? Thanks.

Does this affect any Google Slides document you try? Or can you share a link to a specific document that's affected (obviously, it'd have to be something that's OK to share publicly), so that we can try to reproduce it on another system?

Flags: needinfo?(mchan)

MacOS High Sierra version 10.13.6.

I just opened the same slide on a new tab in an exisitng window I have opened and it works perfectly fine. But when I open the slide on a new window, that's when it goes funny.

Flags: needinfo?(mchan)

Is this bug possibly related to Android text rendering bug 1758678? That bug is in a third party app that uses GeckoView (reproduce by the reporter in version 94 and 98). I don’t know if that bug is also reproduce in Firefox Android.

See Also: → 1758678

The android issue in bug 1758678 looks different, in that it is rendering apparently-randomish garbage in place of the glyphs -- looks like the glyph cache could be broken, for example.

In this case (and similarly in bug 1759948) we're seeing properly rasterized glyphs, they're just the wrong glyphs. I think this most likely means that layout and text shaping has used a particular font, resulting in a set of glyph IDs, but then at webrender drawing time we've failed to use the correct font and we're painting those glyph IDs from an entirely different font, where they don't make sense.

Question for Mandy & Selena: if you open Font and make sure the "All Fonts" view is selected, and then find Arial in the list of fonts, does Font Book indicate that any duplicate fonts are installed? I wonder if there are multiple, incompatible versions of the font present, leading to confusion as to which resource is being used.

Flags: needinfo?(sdeckelmann)
Flags: needinfo?(mchan)

In the Slack thread about this, Eric reports what looks like the same kind of failure happening on Win11, so it's not just Mac users being affected.

Lee, it looks to me like WebRender is painting glyphs from completely the wrong font. Any ideas how we can get to the root of this?

Flags: needinfo?(lsalzman)

What's the earliest version of Firefox that people have seen this on?

Bug 1758555 is my guess for the cause.

mchan, can you please attach your "about:support" information so we can get a better idea about what might be causing this?

If that is from 98 release, then that would be before bug 1758555 landed. If that is from 100 nightly, then it might possibly be related as the font key sharing could conceivably cause it to use the wrong UnscaledFont data for a given ScaledFont.

More often when we see this kind of scrambled text scenario, it is because of some texture cache issue that is causing it to use the wrong page in the texture cache or because a texture cache page failed to allocate. This can be driver bugs or our bugs depending. Hard to say.

Flags: needinfo?(lsalzman)

In the thread on Slack yesterday, both mchan and Selena said that they're on latest Nightly, so that puts bug 1758555 in the frame.

Is there a way to minimally reproduce this to help with debugging? It seems like Google Slides is partially involved, do we have a particular presentation that is accessible and doesn't require involvement of other services like Zoom? If it is bug 1758555, then it should be a deterministic failure that will reproduce reliably with the right steps.

See Also: → 1758555

Could also be conceivably related to bug 1511493.

See Also: → 1511493

I've experimented with Google Slides and Zoom screen-sharing, but so far have not been able to reproduce this locally.

Speculatively, I pushed a try build with a backout of bug 1758555. Mandy and/or Selena, if either of you would be able to try running the build from in place of the standard Nightly, and let us know whether the problem still happens, that would be really helpful.

I saw this bug with Nightly 100 (on Windows 111) on a simple web page that wasn't Google Slides. I wasn't able to reproduce in a clean Nightly profile.

Refreshing the page didn't fix the fonts. Opening the page in multiple tabs didn't fix the fonts. Curiously, when I saved the page as a PDF or took a Firefox screenshot, the PDF or screenshot used the correct fonts.

The bad fonts were only in the SVG?

Flags: needinfo?(cpeterson)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)

The bad fonts were only in the SVG?

Yes. The HTML text on the page was fine. Only the text in the SVG chart was broken.

Flags: needinfo?(cpeterson)
Attached image screenshot.png

I saw this bug again in Google Slides today. Not all of the text is garbled. When I reload the page, the garbled text is initially rendered with the correct letters and then, after about half a second, becomes garbled.

I just ran into what I think is probably this issue (in Linux Nightly 100.0a1 (2022-03-21)) when configuring my Zoom account via the web UI at . When I click my avatar-photo at the top-right, the colorful "LICENSED" text is shown using some weird wingdings-style symbolic font in my Nightly session right now.

See attached screenshot, with Firefox release on left & my current Nightly browsing section on right. Devtools' Font inspector shows Lato Bold supposedly being used in both builds (though clearly it doesn't seem that Nightly is actually using the right font).

In my case on Zoom, the issue (un)fortunately doesn't repro in a fresh profile; and actually, it doesn't reproduce in a new Firefox window in the same session, though it does reproduce in new-tabs in the same Firefox window where I've got it reproducing right now.

The colorful text is being drawn using transparent characters with -webkit-background-clip:text. We are apparently using the wrong characters for the purpose of that background-clipping, but we do show the correct characters if I click and drag to select the transparent text, or if I un-tick the CSS rule for color: transparent.

(Not entirely sure if this is a distinct issue or the same core problem; but in any case it seems ephemeral and similar to the other reports here, so I wanted to capture as much as I could while I've got it reproducing.)

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

Devtools' Font inspector shows Lato Bold supposedly being used in both builds (though clearly it doesn't seem that Nightly is actually using the right font).

From the glyph spacing in the right-hand screenshot, I think it's clear that the text is being laid-out using Lato Bold during content-process reflow (and so from Gecko's point of view, it is reporting the font that it is using); the issue is that the rendering process is then painting the intended Lato Bold glyph IDs using some entirely different font.

I'm fairly sure the problem must lie either in the communication between content and rendering process, or (more likely, IMO) within the webrender process itself; perhaps it's somehow mixing up cached font references or something like that.

(Comment 13 links to a tryserver build with a backout of one possible culprit, but without a reliably reproducible testcase it may be difficult to establish whether it helps or not.)

@lsalzman What would you think of landing a backout of bug 1758555 on Nightly, and see if people still experience the problem or not?

Flags: needinfo?(lsalzman)

I would rather keep bug 1758555 where it is until we can get a reliable testcase. I think backing it out is only going to delay the feedback process, rather than accelerate it until we have a better idea of the causal factors.

Flags: needinfo?(lsalzman)

Hi Lee, not sure what's the best way to provide this information, I've attached a pdf file.

Flags: needinfo?(mchan)
Attached image Front book

Hey Jkew, this is what I see when I open my font book.

I can reproduce on Windows 10.

Steps to reproduce:

  1. Download and install the ColorTube font.
  2. Open data:text/html;charset=utf-8,<select style="font: 35px colortube"><option>こんにちは🙂Hello</option><option>Helloالسلام عليكم</option></select>
  3. Open the <select> menu.

Actual results:

Arabic text is displayed incorrectly.

(In reply to from comment #23)

Hey Jkew, this is what I see when I open my font book.

Thanks! That's odd, it seems to be showing two copies of each of the Arial fonts (2 of "Arial Regular", 2 of "Arial Italic", etc).

If you expand the Arial family by clicking the ► arrow beside it, which should show the list of all the font faces that make up the Arial family, does it show duplicate entries there? E.g. are there two "Regular" entries under Arial, when the list is expanded?

If so, please click each of them in turn and use Show Font Info (see the View menu) to display the details about the individual font files. This should include a "Location" entry showing where on your system the file is found. I'll attach a screenshot showing what I mean.

So if you do have these duplicates, let's find out where they are. It's possible that they may be causing "random", confused behavior.

Here's how the Font Info view in Font Book displays where individual font files are located. (Appearance will be slightly different depending on OS version.) If you have duplicates of the Arial faces, let's find where they are and clean them up.

(In reply to blinky from comment #25)

Regression range:

Thanks! I'll try your testcase and see if it reproduces for me as well (I suspect it may be erratic depending on system details), but this points to bug 1758555 which I think makes sense given the symptoms.

(In reply to blinky from comment #24)

Arabic text is displayed incorrectly.

Can you attach a screenshot of the incorrect rendering you get? Thanks!

Flags: needinfo?(over68)

Here's the screenshot.

Flags: needinfo?(over68)

I can also reproduce with new private window:

data:text/html;charset=utf-8,<select style="font: 35px colortube"><option>国 Hello</option><option>Helloالسلام عليكم</option></select>

Hey Jonathan, here's what I see when I click on "regular" > info. It is showing there are 2 regulars, but the other one is "inactive".

I see from your screenshot that the one in /Library/Fonts/Arial.ttf [inactive] reports itself as version 5.01.2x, with 3381 glyphs. What does the other Regular face (in /Library/Fonts/Microsoft/Arial.ttf) report for its version number and glyph count?

Here it is! Thanks, jkew.

Severity: -- → S2
Priority: -- → P1

(In reply to from comment #34)

Created attachment 9268950 [details]
active Arial-regular font/.png

Here it is! Thanks, jkew.

OK, so the versions in the /Library/Fonts/Microsoft folder (which were presumably put there when installing an MS product such as Office) are newer and more complete than those directly in /Library/Fonts (which would have come with the original Mac system).

Although Font Book says that the /Library/Fonts ones are "inactive", I'm a bit suspicious that the existence of duplicates like this has sometimes caused problems, so I would suggest that you completely remove the older copies of these Arial files from /Library/Fonts (move them to the Trash / Bin). They're not serving any purpose, and may be causing confusion.

However, I think it's becoming increasingly clear that there's a more general font-handling bug in Nightly at the moment, so this may not really solve anything.

Marking this as a regression from bug 1758555, based on the regression range reported in comment 25.

Keywords: regression
Regressed by: 1758555

The blob font tables in Moz2DImageRenderer are currently shared across all WebRender instances.
So if different blob fonts from different WebRender instances happen to share the same font keys,
in particular the same namespace, the font keys can thus accidentally collide and blob fonts can
end up getting shared across WebRender instances unintentionally.

To guard against this, we need to ensure that SharedFontResources is provided with a unique
namespace for the WebRender instance in which to allocate shared font keys so that collisions
can no longer occur.

Assignee: nobody → lsalzman
Pushed by
Ensure shared font keys have a unique namespace per WebRender instance. r=gw,gfx-reviewers
Flags: needinfo?(sdeckelmann)
Pushed by
Ensure shared font keys have a unique namespace per WebRender instance. r=gw,gfx-reviewers
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
Has Regression Range: --- → yes
See Also: → 1759667
Flags: needinfo?(lsalzman)
See Also: → 1761437
Regressions: 1761437
No longer regressions: 1761437
Flags: qe-verify+

I was not able to reproduce the issue on build without the fix 100.0a1(20220321065848) on both Win10 and Mac 10.13. I used the steps from description and the ones from comments #14, #24, #31.
Can you please confirm issue is not reproducing on latest Beta ( Thank you.

Flags: needinfo?(mchan)

It's all working fine now. Cheers.

Flags: needinfo?(mchan)

Marked as verified based on comment#44.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.