New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fonts and crossorigin #32

Closed
yoavweiss opened this Issue Sep 30, 2015 · 17 comments

Comments

Projects
None yet
5 participants
@yoavweiss
Collaborator

yoavweiss commented Sep 30, 2015

If I'm reading obtain the preload resource properly, it'd mean that if a user want to preload a font, they would have to add a crossorigin attribute to the <link>.

I wonder if that the best way to go, or we should special case font to implicitly set crossorigin.
I tend to think special casing font would be better, since users won't have to worry about that. I worry that otherwise, omitting crossorigin and double-downloading the font would be a common error.

In any case, we should address this in the spec: Either change the processing model, or change the examples and add a note.

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Sep 30, 2015

Member

I don't think we can omit crossorigin setting for preload. If we do, (as one example) how would the developer preload an <img crossorigin ... > resource?

As for fonts getting special treatment.. this seems like a bit too much magic. I think it may be even more confusing for fonts to transparently opt-in into this mode, whereas you'd have to still specify the crossorigin attribute for other use cases.

Member

igrigorik commented Sep 30, 2015

I don't think we can omit crossorigin setting for preload. If we do, (as one example) how would the developer preload an <img crossorigin ... > resource?

As for fonts getting special treatment.. this seems like a bit too much magic. I think it may be even more confusing for fonts to transparently opt-in into this mode, whereas you'd have to still specify the crossorigin attribute for other use cases.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Sep 30, 2015

Collaborator

I don't think we can omit crossorigin setting for preload. If we do, (as one example) how would the developer preload an <img crossorigin ... > resource?

Yeah, I wasn't suggesting that we omit crossorigin, just that we implicitly set it for fonts.

As for fonts getting special treatment.. this seems like a bit too much magic. I think it may be even more confusing for fonts to transparently opt-in into this mode, whereas you'd have to still specify the crossorigin attribute for other use cases.

I agree it's magical, but that's already what fonts do... OTOH, I can live with users having to explicitly set crossorigin. FWIW, if we'd see this mistake a lot in the wild, we can always implicitly set crossorigin for font later.

So, if we go that route, we need to change the font examples in the spec, and probably add a note.

Collaborator

yoavweiss commented Sep 30, 2015

I don't think we can omit crossorigin setting for preload. If we do, (as one example) how would the developer preload an <img crossorigin ... > resource?

Yeah, I wasn't suggesting that we omit crossorigin, just that we implicitly set it for fonts.

As for fonts getting special treatment.. this seems like a bit too much magic. I think it may be even more confusing for fonts to transparently opt-in into this mode, whereas you'd have to still specify the crossorigin attribute for other use cases.

I agree it's magical, but that's already what fonts do... OTOH, I can live with users having to explicitly set crossorigin. FWIW, if we'd see this mistake a lot in the wild, we can always implicitly set crossorigin for font later.

So, if we go that route, we need to change the font examples in the spec, and probably add a note.

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Sep 30, 2015

Member

@annevk what happens when I'm self-hosting the font on same origin as the document? Do we force the same flag and cause the UA to open a separate connection? (That would be unfortunate)

Put another way, are there ever cases where fonts are exempt from forcing crossorigin? Do we ever see this behavior changing?

Member

igrigorik commented Sep 30, 2015

@annevk what happens when I'm self-hosting the font on same origin as the document? Do we force the same flag and cause the UA to open a separate connection? (That would be unfortunate)

Put another way, are there ever cases where fonts are exempt from forcing crossorigin? Do we ever see this behavior changing?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 1, 2015

Member

I think "anonymous" in implementations means that the credentials mode is "same-origin", but someone would have to verify that to be sure.

Member

annevk commented Oct 1, 2015

I think "anonymous" in implementations means that the credentials mode is "same-origin", but someone would have to verify that to be sure.

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Oct 6, 2015

Member

I believe that is the case for Chrome.. /cc @mikewest for a sanity check.

@yoavweiss the examples in the spec are all same-origin so I don't think it's strictly necessary to add it? That said, perhaps we should change one of the examples to use a different origin with crossorigin..

Member

igrigorik commented Oct 6, 2015

I believe that is the case for Chrome.. /cc @mikewest for a sanity check.

@yoavweiss the examples in the spec are all same-origin so I don't think it's strictly necessary to add it? That said, perhaps we should change one of the examples to use a different origin with crossorigin..

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Oct 7, 2015

Member

I think that's correct, yes.

I also don't think we should special case <link> for fonts.

Member

mikewest commented Oct 7, 2015

I think that's correct, yes.

I also don't think we should special case <link> for fonts.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Oct 7, 2015

Collaborator

Fair enough.

In that case, let's just add a different origin example for a font that includes a crossorigin attribute.

Collaborator

yoavweiss commented Oct 7, 2015

Fair enough.

In that case, let's just add a different origin example for a font that includes a crossorigin attribute.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Feb 29, 2016

Collaborator

I believe there's some disagreement between the Blink implementation and the spec examples, which we need to sort out.

Currently, Blink's implementation requires the crossorigin attribute also on same-origin font fetches, which means that the spec examples won't work with it.

An IRC conversation with @annevk made me believe that Blink's implementation is right to do so, but re-reading that, I may have asked the wrong question.

Looking at the fonts spec, it fetches fonts with potentially CORS-enabled fetch, which AFAICT would result in "same-origin" fetch for the same-origin case. OTOH, the fetch spec is supposed to supplant the above behavior, but I'm not sure where is that behavior defined.

So, should the preload of fonts from the same origin use the crossorigin attribute? If not, we need to fix Blink's behavior. If it should, we need to fix our examples.

Collaborator

yoavweiss commented Feb 29, 2016

I believe there's some disagreement between the Blink implementation and the spec examples, which we need to sort out.

Currently, Blink's implementation requires the crossorigin attribute also on same-origin font fetches, which means that the spec examples won't work with it.

An IRC conversation with @annevk made me believe that Blink's implementation is right to do so, but re-reading that, I may have asked the wrong question.

Looking at the fonts spec, it fetches fonts with potentially CORS-enabled fetch, which AFAICT would result in "same-origin" fetch for the same-origin case. OTOH, the fetch spec is supposed to supplant the above behavior, but I'm not sure where is that behavior defined.

So, should the preload of fonts from the same origin use the crossorigin attribute? If not, we need to fix Blink's behavior. If it should, we need to fix our examples.

@yoavweiss yoavweiss reopened this Feb 29, 2016

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Feb 29, 2016

Member

If the URL is same-origin the crossorigin attribute has no effect (mode will be "cors", but it doesn't matter).

Member

annevk commented Feb 29, 2016

If the URL is same-origin the crossorigin attribute has no effect (mode will be "cors", but it doesn't matter).

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Feb 29, 2016

Collaborator

Can you elaborate on that?

  • If a font is fetched from the same origin, what should be the mode? "cors" or "same-origin"? Could you point me to the spec sections that define that?
  • Assuming the answer to the above point is "cors", are you saying that same origin "cors" mode requests and same-origin "same-origin" requests can be interchangeably reused?
Collaborator

yoavweiss commented Feb 29, 2016

Can you elaborate on that?

  • If a font is fetched from the same origin, what should be the mode? "cors" or "same-origin"? Could you point me to the spec sections that define that?
  • Assuming the answer to the above point is "cors", are you saying that same origin "cors" mode requests and same-origin "same-origin" requests can be interchangeably reused?
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Feb 29, 2016

Member

CSS doesn't define its integration with Fetch, but Fetch' mode doesn't depend on the URL. (I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

Member

annevk commented Feb 29, 2016

CSS doesn't define its integration with Fetch, but Fetch' mode doesn't depend on the URL. (I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Mar 3, 2016

Member

CSS doesn't define its integration with Fetch, but Fetch' mode doesn't depend on the URL. (I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

Hmm... doesn't the possibility of a redirect force us to treat them as different? As in, I give you a same-origin URL and mark it as crossorigin=anonymous: the request hits the URL and gets back a 3XX to another origin, at which point we have to open a new socket... And while all that is happening, we need to be able to match this in-flight request against other requests asking for same URL, to avoid duplicate downloads.

Also, as far as I understand, one of the motivations behind potentially cors-enabled flag for fonts was to avoid cookies.. which, at least in theory, is applicable to both same and cross-origin cases. (With one big gotcha that fonts require a dedicated socket -- ugh).

Member

igrigorik commented Mar 3, 2016

CSS doesn't define its integration with Fetch, but Fetch' mode doesn't depend on the URL. (I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

Hmm... doesn't the possibility of a redirect force us to treat them as different? As in, I give you a same-origin URL and mark it as crossorigin=anonymous: the request hits the URL and gets back a 3XX to another origin, at which point we have to open a new socket... And while all that is happening, we need to be able to match this in-flight request against other requests asking for same URL, to avoid duplicate downloads.

Also, as far as I understand, one of the motivations behind potentially cors-enabled flag for fonts was to avoid cookies.. which, at least in theory, is applicable to both same and cross-origin cases. (With one big gotcha that fonts require a dedicated socket -- ugh).

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Mar 3, 2016

Member

Cookies are included for same-origin requests, unless you specify "omit" for credentials mode, which almost nothing can do (fetch() and new Worker() can, iirc). Opening a new socket when you cross origins also seems entirely reasonable, given the same-origin policy. Not entirely sure what we're discussing at this point.

Member

annevk commented Mar 3, 2016

Cookies are included for same-origin requests, unless you specify "omit" for credentials mode, which almost nothing can do (fetch() and new Worker() can, iirc). Opening a new socket when you cross origins also seems entirely reasonable, given the same-origin policy. Not entirely sure what we're discussing at this point.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Mar 14, 2016

Collaborator

@igrigorik - seems like both Chrome and Firefox send cookies on same origin font fetches. Regarding the redirect scenario, cross-origin redirects should be CORS, but I don't think it means (or should mean) that non-redirect responses to same-origin requests should not match, nor that same-origin font requests can't use the general socket pool.

Adding @sleevi for Opinions™

(I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

@annevk - Is that defined in Fetch? Also, is "potentially CORS-enabled fetch" defined?

Collaborator

yoavweiss commented Mar 14, 2016

@igrigorik - seems like both Chrome and Firefox send cookies on same origin font fetches. Regarding the redirect scenario, cross-origin redirects should be CORS, but I don't think it means (or should mean) that non-redirect responses to same-origin requests should not match, nor that same-origin font requests can't use the general socket pool.

Adding @sleevi for Opinions™

(I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

@annevk - Is that defined in Fetch? Also, is "potentially CORS-enabled fetch" defined?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Mar 14, 2016

Member

Is that defined in Fetch?

I think it follows from what Fetch defines, yes.

"potentially CORS-enabled fetch" is no longer a thing. It used to be a thing in the HTML standard, but we removed that some months back.

It seems however y'all are quite confused. The socket pool is effectively keyed on origin/credentials. The key for a same-origin fetch will be the origin/true and for a cross-origin fetch will be the origin/false (since the credentials mode for fonts is "same-origin" and the mode will always be "cors").

Member

annevk commented Mar 14, 2016

Is that defined in Fetch?

I think it follows from what Fetch defines, yes.

"potentially CORS-enabled fetch" is no longer a thing. It used to be a thing in the HTML standard, but we removed that some months back.

It seems however y'all are quite confused. The socket pool is effectively keyed on origin/credentials. The key for a same-origin fetch will be the origin/true and for a cross-origin fetch will be the origin/false (since the credentials mode for fonts is "same-origin" and the mode will always be "cors").

@sleevi

This comment has been minimized.

Show comment
Hide comment
@sleevi

sleevi Mar 14, 2016

Having read this thread several times since @yoavweiss reached out, I'm still quite confused as to what "the issue" is. But so far everything @annevk has said sounds right.

sleevi commented Mar 14, 2016

Having read this thread several times since @yoavweiss reached out, I'm still quite confused as to what "the issue" is. But so far everything @annevk has said sounds right.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Mar 14, 2016

Collaborator

OK, let me try to clarify.
Currently, the Chrome implementation requires the addition of a "crossorigin" attribute when preloading fonts from same-origin, or the preloaded resource doesn't match the one requested later on, resulting in a double download.

The issue is me trying to figure out if this is a bug, or if this is the expected behavior and the spec examples should be modified accordingly.
From @annevk's comments I understand that this is an implementation issue.

Collaborator

yoavweiss commented Mar 14, 2016

OK, let me try to clarify.
Currently, the Chrome implementation requires the addition of a "crossorigin" attribute when preloading fonts from same-origin, or the preloaded resource doesn't match the one requested later on, resulting in a double download.

The issue is me trying to figure out if this is a bug, or if this is the expected behavior and the spec examples should be modified accordingly.
From @annevk's comments I understand that this is an implementation issue.

@yoavweiss yoavweiss closed this Mar 15, 2016

fatpixelstudio added a commit to jolantis/altair that referenced this issue Jan 17, 2017

Add cross-origin to font preload, to prevent doulble loading.
Why? Well… That’s a long story.
A good summary can be found here: w3c/preload#32 (comment)

pcraig3 added a commit to cds-snc/ircc-rescheduler that referenced this issue Aug 16, 2018

Add crossorigin="anonymous" so that fonts don't download twice
For some reason, Chrome will download the preloaded fonts, and then
ignore them and re-download them _again_.

Other browsers don't do this -- only Chrome.

If you want to read up on this super weird behaviour:

- w3c/preload#32 (comment)
- https://bugs.chromium.org/p/chromium/issues/detail?id=584198
- https://stackoverflow.com/a/36508361/9728185

And there's a good example in the MDN docs:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link

dsamojlenko pushed a commit to cds-snc/ircc-rescheduler that referenced this issue Sep 1, 2018

Add crossorigin="anonymous" so that fonts don't download twice
For some reason, Chrome will download the preloaded fonts, and then
ignore them and re-download them _again_.

Other browsers don't do this -- only Chrome.

If you want to read up on this super weird behaviour:

- w3c/preload#32 (comment)
- https://bugs.chromium.org/p/chromium/issues/detail?id=584198
- https://stackoverflow.com/a/36508361/9728185

And there's a good example in the MDN docs:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment