Skip to content

LibWeb: Correct initiator origin logic for new top level traversables #8908

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.

Sign up for GitHub

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

Open
jonbgamble wants to merge 1 commit into
base: master
Choose a base branch
from
+46 −1
Open

LibWeb: Correct initiator origin logic for new top level traversables #8908

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Libraries/LibWeb/HTML/TraversableNavigable.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ GC::Ref<TraversableNavigable> TraversableNavigable::create_a_new_top_level_trave
// document: document (now owned by Navigable::m_active_document, not DocumentState)

// initiator origin: null if opener is null; otherwise, document's origin
document_state->set_initiator_origin(opener ? Optional<URL::Origin> {} : document->origin());
document_state->set_initiator_origin(opener ? document->origin() : Optional<URL::Origin> {});
Copy link
Copy Markdown
Member

@shannonbooth shannonbooth Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oof nice spot, any possbility of adding a test for this?


// origin: document's origin
document_state->set_origin(document->origin());
Expand Down
3 changes: 3 additions & 0 deletions Tests/LibWeb/Text/expected/HTML/window-open-about-blank-inherits-opener-origin.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
initial popup.location.href: about:blank
initial popup.document.body.textContent: Hello Shannon!
reloaded popup.document.body.textContent:
42 changes: 42 additions & 0 deletions Tests/LibWeb/Text/input/HTML/window-open-about-blank-inherits-opener-origin.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
<!DOCTYPE html>
<script src="../include.js"></script>
<script>
asyncTest(async done => {
const popup = window.open();
const initialDocument = popup.document;
const initialTextContent = "Hello Shannon!";

println(`initial popup.location.href: ${popup.location.href}`);

try {
popup.document.body.innerHTML = `<p>${initialTextContent}</p>`;
println(`initial popup.document.body.textContent: ${popup.document.body.textContent}`);
} catch (error) {
println(`initial popup document access threw: ${error.name}: ${error.message}`);
}

popup.location.reload();

for (let attempt = 0; attempt < 300; ++attempt) {
try {
const currentDocument = popup.document;
const currentTextContent = currentDocument.body ? currentDocument.body.textContent : "";

if (currentDocument !== initialDocument || currentTextContent !== initialTextContent)
break;
} catch (error) {
}

await timeout(10);
}
Copy link
Copy Markdown
Collaborator

@gmta gmta Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe WPT's standard way of dealing with these types of updates should work immediately; i.e. two nested requestAnimationFrame(..)s and a setTimeout(.., 0) inside of that.

Copy link
Copy Markdown
Member

@shannonbooth shannonbooth Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my understanding (I was wondering how we could do this) what is the magic which makes that timing okay? (specifically 2 animation frames)

Copy link
Copy Markdown
Collaborator

@gmta gmta Apr 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand, the first rAF triggers within the current frame (nothing updated yet), the second one actually enforces executing on the next rendering opportunity (layout/style updated) but might not yet have triggered the painting logic to the point where compositing is done, so the inner setTimeout() makes sure we schedule a task to let painting do its thing and taking a screenshot will reliably work.

For different test cases different combinations of these three might work equally well, but rAF+rAF+setTimeout has been easy to remember as something that "just works" for me. For screenshot tests I can confirm that leaving out any of the three has caused tests to be flaky in the past.

Copy link
Copy Markdown
Contributor Author

@jonbgamble jonbgamble Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could try it, but we're waiting on the popup reload to replace the Document, which likely takes longer than waiting for renders to settle.


try {
println(`reloaded popup.document.body.textContent: ${popup.document.body.textContent}`);
} catch (error) {
println(`reloaded popup document access threw: ${error.name}: ${error.message}`);
}

popup.close();
done();
});
</script>
Loading