1759891 - Seeing funny characters in Google Slides

Status: VERIFIED FIXED

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

Description

[[e-mail]]

Attachment: Screen Shot 2022-03-15 at 18.44.25.png

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

Comment 1

[Jonathan Kew [:jfkthame]]

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?

Comment 2

[[e-mail]]

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.

Comment 4

[Chris Peterson [:cpeterson]]

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.

Comment 5

[Jonathan Kew [:jfkthame]]

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 Book.app 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.

Comment 6

[Jonathan Kew [:jfkthame]]

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?

Comment 7

[Jeff Muizelaar [:jrmuizel]]

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

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Bug 1758555 is my guess for the cause.

Comment 9

[Lee Salzman [:lsalzman]]

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.

Comment 10

[Jonathan Kew [:jfkthame]]

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.

Comment 11

[Lee Salzman [:lsalzman]]

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.

Comment 12

[Lee Salzman [:lsalzman]]

Could also be conceivably related to bug 1511493.

Comment 13

[Jonathan Kew [:jfkthame]]

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 https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/e0E1_wAOTciNfW32IIej7g/runs/0/artifacts/public/build/target.dmg in place of the standard Nightly, and let us know whether the problem still happens, that would be really helpful.

Comment 14

[Chris Peterson [:cpeterson]]

Attachment: cpeterson-screenshot.png

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.

https://cpeterso.github.io/burndown/?status_whiteboard=geckoview:m100&burnup_since=2022-03-03

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.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

The bad fonts were only in the SVG?

Comment 16

[Chris Peterson [: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.

Comment 17

[Chris Peterson [:cpeterson]]

Attachment: 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.

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: screenshot of "LICENSED" text on Zoom

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 https://mozilla.zoom.us/ . 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).

Comment 19

[Daniel Holbert [:dholbert]]

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.)

Comment 20

[Jonathan Kew [:jfkthame]]

(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?

Comment 21

[Lee Salzman [: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.

Comment 22

[[e-mail]]

Attachment: Troubleshooting Information.pdf

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

Comment 23

[[e-mail]]

Attachment: Front book

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

Comment 24

[blinky]

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.

Comment 25

[blinky]

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=80346599cb61135d67d8c1b46d2c60984333d45c&tochange=dc88906824026db14115269cdc9f35f0ed3edbc6

Comment 26

[Jonathan Kew [:jfkthame]]

(In reply to [e-mail] 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.

Comment 27

[Jonathan Kew [:jfkthame]]

Attachment: Font Book screenshot showing the "Location" field for an individual font

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.

Comment 28

[Jonathan Kew [:jfkthame]]

(In reply to blinky from comment #25)

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=80346599cb61135d67d8c1b46d2c60984333d45c&tochange=dc88906824026db14115269cdc9f35f0ed3edbc6

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.

Comment 29

[Jonathan Kew [:jfkthame]]

(In reply to blinky from comment #24)

Arabic text is displayed incorrectly.

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

Comment 30

[blinky]

Here's the screenshot.

Comment 31

[blinky]

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>

Comment 32

[[e-mail]]

Attachment: Inactive Arial-regular font.png

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".

Comment 33

[Jonathan Kew [:jfkthame]]

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?

Comment 34

[[e-mail]]

Attachment: active Arial-regular font/.png

Here it is! Thanks, jkew.

Comment 35

[Jonathan Kew [:jfkthame]]

(In reply to [e-mail] 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.

Comment 36

[Jonathan Kew [:jfkthame]]

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

Comment 37

[Lee Salzman [:lsalzman]]

Attachment: Bug 1759891 - Ensure shared font keys have a unique namespace per WebRender instance. r?gw

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.

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8da43c1bdd49
Ensure shared font keys have a unique namespace per WebRender instance. r=gw,gfx-reviewers

Comment 39

[Atila Butkovits]

Backed out causing Webrender busatges.

Backout link: https://hg.mozilla.org/integration/autoland/rev/73cf808ebf54ed0219d272128d7e459fc2dee5b1

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=8da43c1bdd4930942b5de9116dfda2cdde7dda9a

Failure log: https://treeherder.mozilla.org/logviewer?job_id=372142930&repo=autoland

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/26768254de77
Ensure shared font keys have a unique namespace per WebRender instance. r=gw,gfx-reviewers

Comment 41

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/26768254de77

Comment 43

[Monica Chiorean]

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 (https://archive.mozilla.org/pub/firefox/candidates/100.0b9-candidates/build1/)? Thank you.

Comment 44

[[e-mail]]

It's all working fine now. Cheers.

Comment 46

[Monica Chiorean]

Marked as verified based on comment#44.