1757306 - Link headers not respected for image/media documents

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect, P5)

Description

[Noam Rosenthal]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36

Steps to reproduce:

(1) Open a video or image document via window.open, with Link headers
(2) wait for the document to be loaded
(3) Check the ResourceTiming entries of that document, and whether the resource referenced by the link header was accessed

See https://github.com/web-platform-tests/wpt/pull/32878

Note: this part of the standard has not been fully specified as of today, and this is an attempt to finish the specifications and make things more interoperable. See https://github.com/whatwg/html/pull/7622

Actual results:

The resource was not accessed (it's accessed correctly for HTML/XHTML documents) and there are no RT entries

Expected results:

There should have been a resource access and an RT entry. https://github.com/web-platform-tests/wpt/pull/32878 should pass.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Do we really want to process link headers in media documents? Wouldn't that allow a page to inject styles and e.g. prevent standalone image viewing with rel=stylesheet links?

Comment 3

[Noam Rosenthal]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Do we really want to process link headers in media documents? Wouldn't that allow a page to inject styles and e.g. prevent standalone image viewing with rel=stylesheet links?

Currently the link header spec is only about <link rel=preload>.

Comment 4

[Anne (:annevk)]

FWIW, they can probably already disable standalone image viewing using the Sec-Fetch-Dest request header.

Not saying that's an argument we should do this as I'm not sure of all the implications here, but at least that particular reason does not seem applicable. I do think we should try to think of the implications beyond preload, even if we were to start out with just preload.

Comment 5

[Jim Mathies [:jimm]]

Hey Anne, can you provide some guidance here on what we might need to implement? Also curious if you have a sense of what the priority is here. (For example, if we need to add support for something, can we schedule that in H2 vs. prioritizing now.) Not sure if this falls on DOM or Media but once I understand what we actually plan to implement I can sort that out.

Comment 6

[Anne (:annevk)]

I don't think this is something that ends up mattering in practice as far as I can tell, but us not processing Link elements there in this matter might suggest some code cleanup is in order. This is part of navigation / document creation so I'd argue it's not something the media team needs to tackle. Moving the bug accordingly.