STR:

1. Visit https://www.wired.com/story/beware-a-new-google-drive-scam-landing-in-inboxes/
2. Right-click & inspect the article text, e.g. the 3rd paragraph ("The success of email spam filters[...]") which is clearly all rendered using a single font.
3. Switch to the "Fonts" pane of the inspector, and expand the "All fonts on page" section.

What happened?

The Fonts inspector correctly reports the font used (BreveText / Breve Text Book), but it doesn't show the URL or any info for this font in the "All fonts on page" section. It just shows info for a different SFUIText font in that section.

What should have happened?

The Fonts Inspector should have shown the URL for this Breve Text Book font, specifically:

@font-face {
  font-family: BreveText;
  src: url("https://www.wired.com/verso/static/assets/fonts/BreveText-Book.woff") format("woff");
}

(I found that^ in the DOM inspector, inline inside of a <style id="font-faces"> element.)

Note: I noticed that twisniewski's "testcase reducer" devtools-enhancing addon also has trouble reducing this page (it captures almost none of the CSS), so it's possible there's something going on here (whether intentional or unintentional) that's thwarting our devtools' ability to extract various bits of style info, in general.

Looks like a race condition, which happens more frequently on release. Today it doesn't seem to reproduce on Nightly for us, but I did reproduce it on Nightly a few days ago.

:Honza mentioned there were reports about missing requests for fonts for the network panel (Bug 1027122), so let's check how we are building that part of the inspector panel and see if this is related.

We mostly use the following logic on the actor side to fetch fonts:

    // node.rawNode is defined for NodeActor objects
    const actualNode = node.rawNode || node;
    const contentDocument = actualNode.ownerDocument;
    // We don't get fonts for a node, but for a range
    const rng = contentDocument.createRange();
    const isPseudoElement = Boolean(
      CssLogic.getBindingElementAndPseudo(actualNode).pseudo
    );
    if (isPseudoElement) {
      rng.selectNodeContents(actualNode);
    } else {
      rng.selectNode(actualNode);
    }
    const fonts = InspectorUtils.getUsedFontFaces(rng);
    const fontsArray = [];

I can't seem to debug this efficiently on release, so I'm going to try to see if there's a recent fix which impacted this on Nightly.

We create a range for the whole document, so maybe something around range selection changed?

Daniel: in the meantime, can you check if you still have the issue on Nightly?

Indeed, I can't reproduce on Nightly anymore -- I now see a big list of fonts, including BreveText.

mozregression --find-fix yields:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=665982b5d5e9c99a86592609a925c30cc1e48edb&tochange=7c52caaa2da2c12426a21d6615f6a12a62f4e07b

...which suggests that this was fixed by bug 1816454, which is a bit perplexing, but maybe believable as something that could influence race conditions (?)

I didn't believe it so I tried some targeted launches of the before/after commits:

mozregression --repo autoland --launch 665982b5d5e9c99a86592609a925c30cc1e48edb \
  -a https://www.wired.com/story/beware-a-new-google-drive-scam-landing-in-inboxes/

mozregression --repo autoland --launch 7c52caaa2da2c12426a21d6615f6a12a62f4e07b \
  -a https://www.wired.com/story/beware-a-new-google-drive-scam-landing-in-inboxes/ 

...and indeed, the first one was bad and the second one was good. (In the good build, I actually saw the "All fonts" section being briefly empty and then dynamically populated within a fraction of a second, which seems like things working-as-intended.)

I'm happy to have this closed as WORKSFORME, fixed-by-bug-1816454-somehow -- jdescottes, does that sound OK or would you like to use this for more associated investigation/improvements?

(I should note: in the "bad" builds during my mozregression run, I think only the first visit to the URL was bad. If I reproduced the bug and then reloaded the page, then the issue wouldn't reproduce after the reload, usually. This is consistent with the subtle-race-condition working theory here, I think.)

Thanks for the range from mozregession Daniel! I could no longer reproduce even on 2 weeks old Nightlies after I posted my last comment so I was a bit stuck (I must have been doing something slightly wrong in the STRs).

We should keep the bug open and we will look for more consistent STRs. I imagine Bug 1816454 fixed the issue by chance for this specific page, but it seems unlikely that it really addressed the root cause.

Hmm, I just repeated my first command from comment 5 (for the "last bad build", 665982b5d5e9c99a86592609a925c30cc1e48edb) and I'm now getting expected-results, i.e. no bug.

And then I retried mozregression and I was able to reproduce the bug in Nightly 2023-02-24 (Nightly from the day I filed this bug as well as the latest Nightly, 2022-03-03).

So: I don't think Bug 1816454 actually helped here; it's possible it made it slightly easier to come out favorably from the race condition, but it's not reliably the thing that makes a difference, in my testing today. --> Removing association with it.

Here's a screencast of me reproducing the bug in mozregression-launched Firefox Nightly from today. (Compressed via a video editor so that Bugzilla would accept the attachment; hopefully it's still in a format that can play natively in-browser, apologies if not. Also, my cursor isn't visible, sorry for that.)

I tried reproducing several times after this with the same STR and was unable to do so.

However, I did find that I can reproduce a variant of this issue (not shown here) if I "cheat" by using Network Devtools to throttle my speed, and opening Font Inspector fairly early during the pageload process, and then watching as fonts clearly load but don't show up in Font Inspector. Arguably, we should be updating font-inspector "all fonts on page" dynamically as fonts load, I'd think? I wonder if that's the same root issue or not. Anyway, that's somewhat different from what's captured in this screenshot, but possibly related.