1562968 - Cannot inspect Font Awesome icons when loaded with Subresource Integrity check

Status: UNCONFIRMED

(DevTools :: Inspector, defect, P3)

Description

[fabien.snauwaert]

Attachment: mvce-bug-firefox-inspector-font-awesome.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

1. Open test-fa-buggy.html and edit it to replace the integrity property with one valid for you (this relies on Font Awesome Pro, so you'll need to replace the integrity property with your own to test.)
2. Open the page from the browser via a local web server.
3. Inspect the icon with the Firefox Developer Tools.

Actual results:

The inspect tool returns ZERO information about the icon's CSS, be it when inspecting the icon itself (<i>) or its ::before pseudo-element. See screenshots.

Expected results:

The developer tools should display information as normal. e.g.: font-family, content of the pseudo-element, etc.

Found two separate workarounds:

• Load Font Awesome without integrity check. i.e.: use Font Awesome Free, not Pro.
• Comment out the JavaScript resource that is also relying Subresource Integrity check.

---

Looks like resources loaded with Subresource Integrity check interfere with the Inspector.

I don't think this is a Font Awesome issue, however I cannot fully rule it out. I tried creating a third test (included) with a CSS resource other than Font Awesome that also relies on Subresource Integrity… and it worked fine, can inspect the element's styles… however this is not a font. And in any case this does not explain the inspector not working.

The bug does not occur in Chrome, where inspecting works fine.

Comment 1

[fabien.snauwaert]

Another name for this thread might be:

Cannot inspect Font Awesome Pro icons with Firefox developer tools.

Comment 2

[Hani Yacoub, Desktop QA]

Assigning "DevTools: Inspector: Fonts" component for this bug.

Comment 3

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

The priority flag is not set for this bug.
:rcaliman, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Razvan Caliman [:rcaliman]]

Testing with the latest Nightly, 70.0a1 (2019-08-13) (64-bit), it looks like the broken/empty Rule view occurs because the Font Awesome Pro stylesheet path serves an HTML warning page instead of a CSS file. The parser chokes on the notation (see attached screenshots).

With or without the integrity attribute on the <link>, trying the buggy file on localhost, it seems the stylehseet does load (I see the Firefox icon load), but the Rules panel is blank when inspecting the <i> element. Upon page refresh with DevTools open, the Font Awesome Pro stylesheet loads successfully and both the Rules panel in the Inspector and the Style Editor show it.

Based on this discussion, I presume there's an affordance for the paywalled Font Awesome Pro stylesheet to work on localhost for testing purposes. But the issue symptom seems to be in line with what you're describing: blank Rules panel as a result of the stylesheet URL returning an HTML instead of CSS.

To me, this sounds like an issue when delivering (and checking) the Font Awesome Pro file from the sever. I'm not sure Subresource Integrity (SRI) has anything to do with it on the Firefox end, but I don't have enough knowledge about this to be certain.

I will move this bug to another component to try and get someone else's informed opinion.

Comment 5

[Razvan Caliman [:rcaliman]]

Attachment: buggy-inspector.jpg

Font Awesome Pro URL returns an HTML file which blanks-out the Inspector Rules view.

Comment 6

[Razvan Caliman [:rcaliman]]

Attachment: buggy-styleeditor.jpg

Comment 7

[Razvan Caliman [:rcaliman]]

Attachment: ok-inspector.jpg

On page refresh, the Font Awesome Pro file loads on localhost and the Inspector Rules panel is populated as expected.

Comment 8

[Razvan Caliman [:rcaliman]]

Attachment: ok-styleeeditor.jpg

Comment 9

[Daniel Veditz [:dveditz]]

I don't see any integrity errors in the console, definitely not that. Can you check the browser console for CORS errors? I think this could be a devtools CORS issue.

Comment 10

[Razvan Caliman [:rcaliman]]

Putting it on the backlog. The issue is reproducible, but the root cause it not yet known.
Best guess so far: server misconfiguration serving an HTML file instead of a stylesheet for the paid version of Font Awesome Pro.

Comment 11

[fabien.snauwaert]

Any news on this?

Even if the Font Awesome Pro stylesheet is poorly served by their CDN, it shouldn't block the dev tools.

i.e. if the browser accepts the file and uses it for rendering, then the dev tools should prove just accommodating.

Comment 12

[Razvan Caliman [:rcaliman]]

No updates. It's on our long term backlog now (P3). But we'll gladly review a code contribution if someone can identify the exact root cause and address it.