Closed Bug 2091663 Opened 4 days ago Closed 10 hours ago

[wpt-sync] Sync PR 64351 - WebKit export of https://bugs.webkit.org/show_bug.cgi?id=329441

Categories

(Core :: DOM: Core & HTML, task, P4)

task

Tracking

()

RESOLVED FIXED
162 Branch
Tracking Status
firefox162 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 64351 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/64351
Details from upstream follow.

Anne van Kesteren <annevk@annevk.nl> wrote:

WebKit export of https://bugs.webkit.org/show_bug.cgi?id=329441

WebKit export from bug: A page in the back/<!---->forward cache shares processes with a document of the page in the same browsing context group

<pre>
A page in the back/forward cache shares processes with a document of the page in the same browsing context group

Since <a href="https://commits.webkit.org/324033@main">324033@main</a>, a same-site navigation can move the main frame to another
process when only one of the documents has a Document-Isolation-Policy. The page
stays in its browsing context group, so the document that goes into the
back/forward cache keeps sharing the group's processes with the new one. A frame
of the new document could then be sent to a process where the page's WebPage is
the cached one, and never load, which made
location-replace-keeps-entry.tentative.https.html time out after
isolate-and-require-corp.tentative.https.html. And evicting the cached document
closed the new document's remote pages.

Now, when a document commits, the processes of the page's cached documents in
its group move to groups of their own, with the page's remote pages in them.
Restoring a document moves them back, as long as no other page uses the group.
Otherwise the document is loaded again, or keeps its own group if the other page
only joined during the restore. A cached document with a frame in the process
the new document's main frame started in is dropped from the cache, as that
frame's WebPage became the new document's.

WebKit-Bug: <a href="https://bugs.webkit.org/show_bug.cgi?id=329441">https://bugs.webkit.org/show_bug.cgi?id=329441</a>
</pre>

Component: web-platform-tests → DOM: Core & HTML
Product: Testing → Core

CI Results

Ran 9 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 61 tests and 6 subtests

Status Summary

Firefox

OK : 1[GitHub] 54[Gecko-android-em-14-x86_64-debug-geckoview, Gecko-android-em-14-x86_64-lite-opt-geckoview, Gecko-android-em-14-x86_64-opt-geckoview, Gecko-linux2404-64-debug, Gecko-linux2404-64-opt, Gecko-windows11-32-25h2-debug, Gecko-windows11-32-25h2-opt, Gecko-windows11-64-25h2-debug, Gecko-windows11-64-25h2-opt]
PASS: 181
FAIL: 4[GitHub] 113[Gecko-android-em-14-x86_64-debug-geckoview, Gecko-android-em-14-x86_64-lite-opt-geckoview, Gecko-android-em-14-x86_64-opt-geckoview, Gecko-linux2404-64-debug, Gecko-linux2404-64-opt, Gecko-windows11-32-25h2-debug, Gecko-windows11-32-25h2-opt, Gecko-windows11-64-25h2-debug, Gecko-windows11-64-25h2-opt]

Chrome

OK : 1
PASS: 3
FAIL: 1

Safari

OK : 1
FAIL: 4

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

Tests Disabled in Gecko Infrastructure

Status: NEW → RESOLVED
Closed: 10 hours ago
Resolution: --- → FIXED
Target Milestone: --- → 162 Branch
You need to log in before you can comment on or make changes to this bug.