New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 783416 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jul 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

WPT-prescribed cross-origins are not cross-site

Project Member Reported by lukasza@chromium.org, Nov 9 2017

Issue description

https://github.com/w3c/web-platform-tests#running-the-tests lists the following hostnames used by WPT:

127.0.0.1   web-platform.test
127.0.0.1   www.web-platform.test
127.0.0.1   www1.web-platform.test
127.0.0.1   www2.web-platform.test
127.0.0.1   xn--n8j6ds53lwwkrqhv28a.web-platform.test
127.0.0.1   xn--lve-6lad.web-platform.test
0.0.0.0     nonexistent-origin.web-platform.test

All of the hostnames above can be used for testing cross-origin, but they all end up being same-site and therefore don't get any OOPIF coverage on Chromium bots (even with --site-per-process).

In the short-term, we can increase OOPIF coverage by explicitly isolating all of the origins above (see https://crrev.com/c/729242).  Let's use this bug to discuss what the long-term should be - maybe it is possible to make the hostnames above cross-site (e.g. www.web-platform1.test, www.web-platform2.test, etc.).
 
Cc: qyears...@chromium.org
Owner: foolip@chromium.org
Status: Assigned (was: Untriaged)
foolip@ - I wonder if you could comment on this bug?  Feel free to reassign to other WPT owners as needed.
This is somewhat related to  issue 776532 .
Yes, it'd be good to figure out the right strategy for this.  The concern with our approach in https://crrev.com/c/729242 is that this explicitly breaks things like document.domain for process-isolated origins, so we have to skip tests like external/wpt/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_setter.html.  It'd be nice if the tests that utilize document.domain used the existing hosts, but everything else used cross-site hosts, as Lukasz mentions.
Would the solution be to have wpt require 1 more origin under the top level test. domain? For example:

127.0.0.1 unrelated.test
127.0.0.1 www.unrelated.test
RE: #c4

Yes, but the next question would be - how to make sure that the new origin is actually used in tests:

1. How to migrate existing tests to the new origin
2. How to help people find and use the new origin for new tests (would deleting other origins help?  same-site origins are not needed except for document.domain-dependent tests)

Comment 6 by foolip@chromium.org, Nov 14 2017

Status: ExternalDependency (was: Assigned)
This is https://github.com/w3c/web-platform-tests/issues/2669, and the fix will be to add a not-web-platform.test domain for this.

Comment 7 by foolip@chromium.org, Nov 14 2017

Components: Blink>Infra>Ecosystem
Labels: -Pri-3 Pri-2

Comment 8 by foolip@chromium.org, Nov 21 2017

Cc: foolip@chromium.org
Owner: ----
Unassigning to make it clear I'm not personally working on this, but both this and the GitHub issue will come up in triage again due to their priorities.

Comment 9 by foolip@chromium.org, Jan 23 2018

Update: https://github.com/w3c/web-platform-tests/issues/2669 is on the planning for Q1 and Geoffrey is working on it.
Friendly ping. Any update?

(Doing triage of Blink>Infra P2 issues that's not updated for 60+ days)
Owner: lukasza@chromium.org
Status: Assigned (was: ExternalDependency)
https://github.com/w3c/web-platform-tests/issues/2669 has been fixed upstream now. lukasza@, can you check if this now works in Chromium? It may be that it requires some work on our side, but trying to use it is an effective way to find out.
Status: Fixed (was: Assigned)
This came up in triage again, I'll assume it's fixed of mkwst@ or someone would have noticed by now.

Sign in to add a comment