crossorigin attribute is not honored for [rel=icon] links
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | fixed |
People
(Reporter: jugglinmike, Assigned: andreu)
References
Details
(Keywords: dev-doc-complete)
Attachments
(2 files, 2 obsolete files)
OS: GNU/Linux Ubuntu 18.04
Browser: Firefox Nightly 81.0a1 (2020-08-21)
Steps to reproduce the problem:
-
Open the attached document in the browser (contents included here for clarity):
<!DOCTYPE html> <html lang="en"> <meta charset="utf-8"> <link rel="icon" href="https://www.w3.org/2008/site/images/favicon.ico" crossorigin>
Expected result: the browser does not associate the referenced image with the current document (because the image is not served with the appropriate CORS headers)
Actual result: the browser associates the referenced image with the current document
The attached document sets the crossorigin attribute to "anonymous", but the bug is also present for the empty value ("") and for "use-credentials".
According to the "default fetch and process the linked resource" algorithm:
- Let corsAttributeState be the current state of the el's
crossorigincontent attribute.
https://html.spec.whatwg.org/multipage/semantics.html#fetch-and-process-the-linked-resource
Which is used in "create a potential-CORS request":
- Let mode be "no-cors" if corsAttributeState is No CORS, and "cors" otherwise.
https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
Fetch's "main fetch":
Otherwise,
- Set request’s response tainting to "cors".
- Return the result of performing an HTTP fetch using request.
https://fetch.spec.whatwg.org/#concept-main-fetch
And "HTTP fetch":
- If request’s response tainting is "cors" and a CORS check for request and
response returns failure, then return a network error.
https://fetch.spec.whatwg.org/#concept-http-fetch
This behavior suggests that the request's mode is being set to "no-cors" regardless of the value of the crossorigin attribute. Likewise, the request header Sec-Fetch-Mode is set to "no-cors" in all cases.
|
Reporter | |
Comment 1•4 years ago
|
||
The unexpected behavior is also exhibited by Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1121645
|
|
Reporter | |
Comment 2•4 years ago
|
||
Hey Anne! Given that Firefox and Chromium currently agree on this, I may have misinterpreted something. Even in that case, though, a spec change may be in order, since it seems like this request's "destination" ought to be "image", and we'd need a custom "fetch and process the linked resource" algorithm for that. I'm happy to follow up with spec patches as necessary.
|
||
Comment 3•4 years ago
|
||
I think that this is something that we'd ideally support CORS for to (in theory) allow the image to be used in several places with the same backing cache. I agree with you that the destination ought to be "image". If you can fix that standards-wise that'd be great.
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 4•4 years ago
|
||
There's already a hook for this sort of thing, so the spec patch is surprisingly small: https://github.com/whatwg/html/pull/5866
|
Assignee | |
Comment 5•4 years ago
|
||
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 6•4 years ago
|
||
|
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 7•4 years ago
|
||
|
|
||
Updated•4 years ago
|
Pushed by nbeleuzu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4694136096a2 Switch the security checks when loading favicons depending on the crossorigin attribute. r=mossop
|
||
Comment 9•4 years ago
|
||
| bugherder | ||
|
|
||
Comment 10•4 years ago
|
||
Suggested text for MDN: "The crossorigin attribute is now supported for <link rel=icon>."
|
||
Comment 11•4 years ago
|
||
Looks like the docs have been completed for this one; see https://github.com/mdn/sprints/issues/3802 for the full details.
Description
•