1809894 - Early Hints: wpt iframe-pdf.h2.window.js.ini is failing

Status: NEW

(Core :: Networking: HTTP, defect, P3)

Comment 1

[Manuel Bucher [:manuel]]

This tests fails with:

  FAIL Early hints for an iframe of which content is pdf should be ignored. - promise_test: Unhandled rejection with value: object "SecurityError: Permission denied to access property "performance" on cross-origin object"

So the test needs to be adapted to also work on firefox.

Comment 2

[Manuel Bucher [:manuel]]

Message in devtools:

Partitioned cookie or storage access was provided to “https://web-platform.test:9000/loading/early-hints/resources/pdf-with-early-hints.h2.py?resource-url=https%3A%2F%2Fweb-platform.test%3A9000%2Floading%2Fearly-hints%2Fresources%2Fempty.js%3F82144d6b-5f57-4000-8cc0-4c759722050e&token=bbc83adb-28a8-4e32-9aa8-ac3e734ada9c” because it is loaded in the third-party context and dynamic state partitioning is enabled. Learn more

The iframe isn't cross origin. Both are on https://web-platform.test:9000

When running ./mach test testing/web-platform/tests/loading/early-hints/iframe-pdf.h2.window.js

Accessing the iframe with iframe.contentWindow.performance fails in

https://searchfox.org/mozilla-central/rev/d9dbf648b2f7557f6f06d27cce58546cc539cb2b/testing/web-platform/tests/loading/early-hints/iframe-pdf.h2.window.js#24

const iframe_entries = iframe.contentWindow.performance.getEntriesByName(resource_url);

with

SecurityError: Permission denied to access property "performance" on cross-origin object

As far as I understand it, this is an interaction between iframes and the pdf-viewer. Somehow it gets classified as cross-origin.

In if (AntiTrackingUtils::IsThirdPartyChannel(aChannel)) IsThirdPartyChannel returns true, although the pdf is same-origin.

Tim, it looks like you might know more, because you added the checks for IsThirdParty. Can you take a look?

Comment 3

[Tim Huang[:timhuang]]

It's because the pdf-viewer is running under the origin resource://pdf.js but not the https://web-platform.test:9000. So, we treat it as a cross-origin iframe.

Comment 4

[Manuel Bucher [:manuel]]

Is that intended? How do we want to go forward with this one? Do/Can we need to fix that it is considered cross origin or is a different test setup necessary?

Comment 5

[Manuel Bucher [:manuel]]

It doesn't look intended that we block access to the performance attribute, because the pdf in the iframe has the same origin. We might want to strip the "resource://pdf.js/"-prefix before doing the cross origin check? Christoph, it looks like you worked on similar bugs (Bug 1582115 and Bug 1638826). Can you tell how to proceed with this bug?

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

Gjis, you are my pdf.js go to person.

I don't know how pdf.js is structured internally. Could someone actually query information from it? I mean, could someone (like a cross origin iframe) access and exfiltrate information from the PDF? If not, then I guess we could hack some special case for resource://pdf.js in the ScriptSecurityManager.

What's your take?

Comment 7

[:Gijs (he/him)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #6)

Gjis, you are my pdf.js go to person.

I don't know how pdf.js is structured internally. Could someone actually query information from it? I mean, could someone (like a cross origin iframe) access and exfiltrate information from the PDF? If not, then I guess we could hack some special case for resource://pdf.js in the ScriptSecurityManager.

What's your take?

There are some script things that the PDF viewer does that talk to the parent process etc. that we might not want to provide to web content, so I'm not enthusiastic about making all of it same-origin with web content.

I'm missing some context here though - what's the concrete impact being reported here? Is the test failure indicative of us violating web standards in some way, and if so how exactly? Or is it "just" that that the automated test assumed it could access the PDF frame and it actually cannot? What do other browsers do with their PDF viewers - are those same origin if the PDF is same-origin? That seems... potentially "interesting" depending on the permissions of those viewers... from a quick look, it seems Chrome creates a dummy document which is same-origin, has the PDF as location.href, has a performance object etc, but has no content other than another embed, and the contents of that are x-origin and not accessible to the page...

I can't imagine there's a web spec for this kind of thing but maybe I'm wrong about that?

Assuming this isn't indicative of web spec failures but of how the test is written, perhaps there's some way of granting the test the necessary superpowers to get the performance object of the x-origin frame?

Comment 8

[Manuel Bucher [:manuel]]

The thing being tested here (early hint on pdf) is something different than the failure (accessing performance on pdf iframes). I'm not aware of any spec accessing the pdf iframe mandating the performance attribute.
The way forward would be to fix the wpt to not rely on that attribute. It's not high priority, but I will eventually get back to it. Unassigning me for now.