749245 - First query by Style Inspector to DOMUtils getUsedFontFaces() on a page doesn't return downloadable font

Status: NEW

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

Description

[Heather Arthur [:harth]]

Attachment: patch to fx-team to highlight the rendered font in the Style Inspector

The first time you query getUsedFontFaces(range) on a webpage it won't return the downloadable font if that is the font applied to the range.

This happens even if you query well after the page is loaded and all the fonts have been downloaded and applied.

If you query the same element again on a setTimeout of 0, you'll get the downloadable font.

If you query another element first, then query the element with the downloadable font, you'll get the downloadable font.

This affects bug 702581. I've attached a patch for highlighting the rendered font in the inspector's Rules view. Unfortunately I can't reproduce this problem with a scratchpad. To reproduce this problem:

STR:
1. Apply the attached patch
2. visit http://harthur.github.com/test-pages/fonts.html
3. right click on the big "Women Who Code SF" header and select "Inpsect Element"
4. Open the "Style" panel from the devtools that pop up.

Expected:
See the font-family listing with "BrandonGrotesque" highlighted and the rest of the fonts greyed out.

Actual:
See this font-family with "Helvetica Neue" highlighted.

Comment 1

[Heather Arthur [:harth]]

Attachment: patch to fx-team to highlight the rendered font in the Style Inspector

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Heather Arthur [:harth] from comment #0)
> The first time you query getUsedFontFaces(range) on a webpage it won't
> return the downloadable font if that is the font applied to the range.

Something I find puzzling here is that the fontinfo add-on also relies on the getUsedFontFaces api, but doesn't seem to suffer from this problem - the first query it makes on a page correctly returns the downloadable font being used (if applicable).

Comment 3

[Jonathan Kew [:jfkthame]]

With your patch on a current mozilla-inbound tree, I'm seeing that even after the setTimeout, the wrong font is still reported (as shown by the debug messages printed to the terminal), although if I query another element and then the title again, I get the proper result.

Experimenting with other pages that use webfonts, the behavior seems erratic: the first Inspect Element on http://opentype.info/demo/webfontdemo.html seems to consistently show the right result, whereas on http://fontdeck.com/ the results vary, with some queries giving the expected result and others not.

However, I have not seen any such unreliability with the Show Fonts in Selection command from the fontinfo addon, even though it also relies on getUsedFontFaces().

Comment 4

[Jonathan Kew [:jfkthame]]

I'm speculating here, but I think what may be happening is that opening the inspector is triggering a re-load of the document's stylesheet(s), which in turn causes the user font set to be rebuilt and marked as modified; and this makes us reload the fonts. Unfortunately, the style inspector proceeds to force text-run creation (in order to query the fonts being used) before the font-face loader has had a chance to run (even though the load would be fast, as they'll normally be in cache), and so it sees the fallback that would be used while waiting for the download to complete.

If you can prevent the inspector triggering a stylesheet reload (or re-parse? I don't see it actually making a network request), I suspect the problem would go away. Or if the user font set could somehow detect that the new @font-face rules are in fact identical to the old ones, so that it doesn't need to bump its generation and invalidate old text-runs, we'd probably avoid the issue.

Comment 5

[Jonathan Kew [:jfkthame]]

cc'ing dbaron in the hope that he might have insight into the possible style-system aspects of this.