1755425 - Japanese fonts don't load after restarting from crash

Status: UNCONFIRMED

(Core :: Graphics: Text, defect)

Description

[raphael]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

• Browse the web (for example twitter.com)
• Have Firefox crash (getting the crash reporter)
• Hit "Restart Firefox"

Actual results:

• Japanese fonts seem to be unloaded, showing many "unknown unicode characters"
• I believe that the fonts across the system have also changed?

Closing firefox entirely and re-opening it seems to fix it though

(I don't have a screenshot right now, will try to include one when it happens again, or if someone could tell me a way to trigger a crash somehow...)

Expected results:

The reloaded Firefox to have fonts that work as well as when I freshly open it.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to raphael from comment #0)

(I don't have a screenshot right now, will try to include one when it happens again, or if someone could tell me a way to trigger a crash somehow...)

You could try entering about:crashcontent in the address bar, and see if that reproduces the issue for you.

Comment 3

[raphael]

Unfortunately that doesn't seem to reproduce it. That page does the "crashed tab" thing, but the issue I was having was causing all of Firefox to crash (so all the tabs disappear and then I get a dialog asking to restart firefox).

Comment 4

[Jonathan Kew [:jfkthame]]

Oh, sorry - I misunderstood what kind of crash this was about. In that case, about:crashparent might be worth trying, to see if the problem is consistently reproducible.

Comment 5

[raphael]

Alright so... that didn't successfully reproduce my issue, but it did lead me to https://crash-stats.mozilla.org/report/index/b3d1b029-781a-4d95-b08b-3766f0220126#tab-details, which is one of these crashes. It does seem to have been failing during some font manipulation, which tracks with the issue I was seeing.

Feel free to ask me to run certain things if you need more information about what could be going on.

Comment 6

[Jonathan Kew [:jfkthame]]

That reminds me of bug 1720573, which was also about failures with Asian fonts.... I suspect it may be the same issue, but I don't think we ever figured out what was causing it.

Moving to the Graphics component, as it looks like the failure is on that side of things rather than at the layout level.

Comment 7

[raphael]

The result for me is seeing a lot of "invalid unicode character" symbols, rather than it being completely blank.

This issue might be related? I am on Ubuntu and while I just rely on the OS to manage Firefox, it ... might be the snap version? Unsure of how to figure that out.

Comment 8

[raphael]

OK I confirmed I am using the Firefox Snap version, according to the "About Firefox" modal

Comment 9

[Jamie Nicol [:jnicol]]

Are you able to test a non-snap version and see if that works correctly?

Comment 10

[raphael]

OK so I couldn't really get this to happen on a non-snap version but I dug around in the code a bit....

Over in webrender (unix/font.rs) there's a panic! call when adding a font face fails. When it fails it reports the error code given by FreeType.

That code is actually calling FreeType's FT_New_Face call, and returning its error code. (docs for that)

The error code in the crash reports was always 1, which is "resource not available" for the FreeType error codes

I put the following test at the bottom of the unix/font.rs file:

#[cfg(test)]
mod test {
    use api::IdNamespace;
    use api::NativeFontHandle;
    use std::path::PathBuf;
    use super::*;
    #[test]
    fn assert_can_load_files() {
        let mut fc = FontContext::new().expect("Building Font Context Failed");
        let fk = FontKey::new(IdNamespace(1), 10);
        fc.add_native_font(
            &fk,
            NativeFontHandle {
                path: PathBuf::from("/usr/share/fonts/truetype/liberation/LiberationSans-Bold.ttf"),
                index: 0,
            },
        );
    }
}

Ran with cargo test --package webrender --lib -- platform::unix::font::test::assert_can_load_files --exact --nocapture inside that directory....

now if I put a misspelling in the path, I get a panic with error code of 1.

---

So this comes back to Firefox. It's trying to get the fonts at /usr/share/fonts/ , but there are reports of people being unable to get fonts to work outside of user-installed fonts for stuff like libre office (the Snap package, not the non-Snap one).

So my guess here is that something about the Snap setup is causing FF to not be allowed access to some system installed fonts.... sometimes?

My lack of knowledge of how Snap does its isolation and workarounds makes it a bit hard for me to go deeper into the theory, but I bet that whoever handles the Snap packaging could have some ideas (and probably build out a real reproduction)

Comment 11

[raphael]

OK I have been using the non-Snap FF for a while now and didn't get a single font-related crash (got some other crash from like... Wayland nonsense but that's fine).

So yeah, I believe this is related to this related issue