Navigation test flakiness continues, so relanding.
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
This CL introduces an alternate approach, more similar to what is done
for self.crossOriginIsolated in
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
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
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
Commit-Queue: Domenic Denicola \<firstname.lastname@example.org>
Reviewed-by: Charlie Reis \<email@example.com>
Reviewed-by: Daniel Cheng \<firstname.lastname@example.org>