Bug 1656692 [wpt PR 24842] - Reland "Origin isolation: a new strategy for window...

Bug 1656692 [wpt PR 24842] - Reland "Origin isolation: a new strategy for window.originIsolationRestricted", a=testonly

Automatic update from web-platform-tests
Reland "Origin isolation: a new strategy for window.originIsolationRestricted"

This is a reland of 7ac0b9ed68d57270b680e39b9e21e1ede1b8c774

Navigation test flakiness continues, so relanding.

Original change's description:
> Origin isolation: a new strategy for window.originIsolationRestricted
>
> In https://chromium-review.googlesource.com/c/chromium/src/+/2243994 I
> introduced an implementation for window.originIsolationRestricted which
> pipes the isolation state from NavigationRequest to the navigated-to
> LocalDOMWindow. However, this does not work for the case of the initial
> about:blank, where no navigation is performed. Furthermore, it does not
> match the spec, where the Window property just reflects an agent
> cluster-wide property.
>
> This CL introduces an alternate approach, more similar to what is done
> for self.crossOriginIsolated in
> https://chromium-review.googlesource.com/c/chromium/src/+/2247463, which
> is another agent cluster-wide value. The origin isolation state is
> stored in the renderer-side Agent class. Then the LocalDOMWindow getter
> can just pick it up from the surrounding agent, as in the spec. Note
> that unlike the implementation for self.crossOriginIsolated, the value
> is per-Agent instead of static (process-wide).
>
> Currently the value is set several times per agent (roughly once on
> every navigation). This is redundant, but we don't yet have a good place
> to set it once (i.e., we don't have a browser-side "time of agent
> creation"). If that gets fixed, we can likely stop piping the value
> through navigation params. See
> https://docs.google.com/document/d/1MTnmyWAoAIKDH4yWaRthIUdi05MsjlML8gctvKP7-h8/edit
> for discussions around fixing that.
>
> This fixes the issue with about:blank iframes embedded in origin-isolated
> pages reporting false, because the agent's origin-isolated boolean was
> previously set to true by the containing frame.
>
> This does not yet fix the issue with data: URLs reporting false, tested in
> external/wpt/origin-isolation/getter-special-cases/data-url.https.html.
> However, that will be doable as a followup, by changing the
> navigation-time computation to pass true for them instead of false.
> (Currently it passes false because data: URLs don't get their own
> process, but it should pass true because they _do_ get their own agent
> cluster.)
>
> Bug: 1095653
> Change-Id: I8dfa8fc4a4766efc0611d43a255673662c422776
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2300237
> Commit-Queue: Domenic Denicola <domenic@chromium.org>
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#793799}

Bug: 1095653
Change-Id: Ib061cd0832353bee4f77219628534b64d7a3637e
No-Presubmit: True
No-Tree-Checks: True
No-Try: True
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2333750
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#793905}

--

wpt-commits: fe13f0a2d4a104d659ac03c9621afd20cfb47153
wpt-pr: 24842