1872569 - Failed font loading from "localhost" due to CORS

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, defect)

Description

[Master ? [:masterquestionable]]

    See: https://bugzilla.mozilla.org/show_bug.cgi?id=1872503#c1
    Tested image loading via "url" works.

Comment 2

[Master ? [:masterquestionable]]

    Though related, this is a separate issue.
    Not duplicate.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Let's reopen for further investigation. How do you set up the web server locally so that we can reproduce? Also is there any error message in the web console?

Comment 4

[Master ? [:masterquestionable]]

    Sorry for delayed reply.
    As unable to edit own posts on Bugzilla, and to avoid confusion caused by misinformation:
    My posts on Bugzilla will be extended verified before commit.
    .
    And staged reply is not used.

    Check [ https://bugzilla.mozilla.org/show_bug.cgi?id=1806171#c9 ].
    Also my recent posts:
    https://bugzilla.mozilla.org/buglist.cgi?email1=[e-mail]&emailtype1=exact&emailreporter1=1&emaillongdesc1=1&splitheader=1&columnlist=bug_type,longdescs.count,short_desc,product,component,reporter,bug_status,resolution,opendate,changeddate&order=changeddate%20DESC,reporter,short_desc

    No message generated in the Dev console.

Comment 5

[Daniel Holbert [:dholbert]]

Could you clarify what issue you're reporting here, and ideally post a testcase that demonstrates the issue? Or alternately, the following might explain what you're seeing here, if I'm understanding things correctly.

I think I may have reconstructed what you're describing locally, but I'm not sure.

My setup: two local web servers (using python3 -m http.server [port]), one hosting some HTML, one hosting a font. The first one references a webfont hosted on the other one. (I used the webfont that you linked in bug 1872503 comment 1.) The font does indeed fail to get used (in Firefox as well as in Chrome), and Firefox DevTools shows me this error/explanation:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8999/NotoSansMono-Regular.ttf. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

downloadable font: download failed (font-family: "NotoSansMono-Regular" style:normal weight:400 stretch:100 src index:0): bad URI or cross-site access not allowed
source: http://localhost:8999/NotoSansMono-Regular.ttf

The note about Access-Control-Allow-Origin is a hint. Cross-site font loads are not allowed by default on the web unless allowed via CORS and the Access-Control-Allow-Origin header in particular. Images don't have this restriction, for historical reasons (too much of the legacy web would break if this restriction were added). I think that explains your mention in comment 0 here of 'image loading via "url" works', where I think you're observing that font load is rejected but the image load is allowed. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#what_requests_use_cors for some documentation on this.

Comment 6

[Master ? [:masterquestionable]]

    Exactly [ https://bugzilla.mozilla.org/show_bug.cgi?id=1839806#c13 ]: tested with the cookie page with the script injection of [ https://bugzilla.mozilla.org/show_bug.cgi?id=1872503#c1 ].
    Changed "localhost" to "127.0.0.1" worked...

    The behavior with Access-Control-Allow-Origin absent is not clearly defined.
    Seems browsers have taken the more restrictive approach.
    But such design should be carefully conducted: lest breaking things unnecessarily.

    The whole problem CORS is trying to solve is CSRF: eventually caused by the implicit Cookie handling of web request interfaces (XHR etc.).
    All already accomplishable by not passing the Cookie header when not accessing same-site ("1p") resources. ("3p" no cookie)
    While CORS has invented so much... no idea what it intends.
    All I see is broken things with no security gain...

    Sorry for the jargon. But simple Google Search for the term works.

Comment 7

[Master ? [:masterquestionable]]

    Thanks for your hint.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Master ? [:masterquestionable] from comment #6)

    The behavior with Access-Control-Allow-Origin absent is not clearly defined.

It's clearly defined in the spec, at least.
https://fetch.spec.whatwg.org/#cors-check

(It might not be clear to web developers what's going on, but that's out-of-scope for something to be fixed in the Firefox bug tracker.)

Just clarifying where we've landed here: I think your report here is a case where you're disagreeing with CORS as-it-functions on the web, but there's no Firefox-specific issue here, correct?

Comment 9

[Master ? [:masterquestionable]]

    There are more than just Fetch API.
    And it has been de facto undefined: whatever written in the standard.

    It's worth to reconsider the design and reimplement what's apparently broken.

    Could Firefox avoid such generic issue..?

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Master ? [:masterquestionable] from comment #9)

    There are more than just Fetch API.

The spec that I linked isn't just defining the Fetch API; its the canonical definition of web requests in general ("how to fetch resources", including fonts referenced via CSS as in your setup here.)

Reading the rest of your comment and your other comments here, I'm still having a bit of a hard time understanding you, but it sounds like your issue isn't with Firefox-in-particular, but with CORS itself (as implemented in all browsers).

We're not going to unilaterally change Firefox to diverge from behavior that's standardized & interoperable-with-other-browsers here, so I'm resolving this as INVALID, i.e. not-a-Firefox-bug. If you really want to propose a change in behavior here, your efforts would be best-spent by using the "participate" links at the top of https://fetch.spec.whatwg.org/ to propose & justify concrete changes to the spec.

Comment 11

[Master ? [:masterquestionable]]

    Perhaps, indeed. Thanks for your advice.
    Diverging from the standard does not necessarily mean non-interoperable: I don't make short-sighted designs.

    Simple summary: CORS unnecessarily breaks things without gaining security.

    I see. It's mostly Fetch related.
    Caveat it's "web requests in general" in HTML and JavaScript: not generally "in general".