Skip to content
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

[Spec] Specify way to exempt URLs from network revocation #192

Open
blu25 opened this issue Sep 12, 2024 · 3 comments
Open

[Spec] Specify way to exempt URLs from network revocation #192

blu25 opened this issue Sep 12, 2024 · 3 comments

Comments

@blu25
Copy link
Collaborator

blu25 commented Sep 12, 2024

For web platform tests, we still need to be able to communicate with a fenced frame after network revocation in order to test that certain functionalities stop working. We currently do this with an Chromium-specific window.internals API that allows specified URLs to be exempt from network revocation. To launch network revocation with working tests to the wider community, we will need to have a web driver API that does the same thing. This will require a change to the WPT web driver + an RFC opened for it.

@domfarolino
Copy link
Collaborator

Can you describe why this is important / why we filed this? It isn't for web-exposed behavior right? Testing-only? (A brief description of how this came about / what PR prompted this would be good).

@VergeA
Copy link
Collaborator

VergeA commented Dec 10, 2024

I can provide some more context:

Writing WPTs for fenced frames is hard, because we can't directly communicate data between the fenced frame and the test harness. This is by design, because fenced frames don't have access to communication channels like postMessage() that are commonly used in iframe WPTs. To get around this, we use a RemoteContext executor to send RPCs between the harness and the fenced frame over the network. This allow the test harness to observe behavior that occurs in the fenced frame, and assert on that behavior.

When a fenced frame disable network access, that will include requests sent to the RemoteContext URL used for testing. Meaning, we'll lose our last channel to observe fenced frame behavior in tests. The new window.internals API we added to Chrome was intended to exempt RemoteContext URLs from network revocation, so that we can still write tests against fenced frames.

In order to allow our WPTs to be truly cross-platform, we'd need to standardize an interface by which all browsers can "exempt URLs from network revocation" in tests. This is where the WPT webdriver change + RFC come in.

@domfarolino
Copy link
Collaborator

That makes sense, if you have started the web driver / RFC process, please link to it here. I think it's an important task!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants