GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Make named window lookup more precise and correct BCG swap logic by kjmcnee · Pull Request #10818 · whatwg/html

Conversation

@kjmcnee

@kjmcnee kjmcnee commented Dec 4, 2024 •
edited by pr-preview Bot
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

In "the rules for choosing a navigable," the method to find an existing navigable by name is vague. This updates the definition to accurately reflect what the major implementations do. There are some differences between implementations, so there remains in the spec some optional/implementation-defined behavior, but it's much narrower. In particular, note that lookups are now explicitly scoped to browsing context groups. The previous language in the named lookup about "the user agent determines that the two browsing contexts are related enough" is now no longer a part of the lookup logic, but a consequence of the BCG swap decisions.

In "obtain a browsing context to use for a navigation response," the existing spec only mentions COOP enforcement as a reason to do a browsing context group swap. Some implementations perform a swap for additional security and performance reasons. This is now reflected in the spec.

For context, see:

  • Disowning owner should perhaps affect link targeting #313
  • Introduce a browsing context group #4198 (comment)
  • Impact of browsing context group switch during navigation #5350

This closes #313, but we have opened the following issues to track the remaining implementation-defined interop gaps: #6356, #10842, #10848, #10849, #10850.

  • At least two implementers are interested (and none opposed):
    • This matches all implementations as best we can tell, leaving for-now-implementation-defined gaps where they disagree.
  • Tests are written and can be reviewed and commented upon at:
    • Add WPTs for named window lookup and BCG swap limits web-platform-tests/wpt#49631
  • Implementation bugs are filed:
    • Chromium: not needed for now as this documents existing behavior
    • Gecko: not needed for now as this documents existing behavior
    • WebKit: not needed for now as this documents existing behavior
    • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
    • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
  • Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
  • MDN issue is filed: Probably N/A as this is pretty detailed? E.g. https://developer.mozilla.org/en-US/docs/Web/API/Window/open doesn't get into this level of detail.
  • The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)


/acknowledgements.html ( diff )
/browsers.html ( diff )
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@domenic

domenic commented Dec 4, 2024

Copy link
Copy Markdown
Member

Oh my goodness, what a great early Christmas gift!!

@annevk, do you want to take a look? I can help with editorial review and tweaks but I'd like to know how you feel about the approach to normative algorithm and strategy.

@kjmcnee, do you think there are web platform tests we could write for this, despite the remaining implementation-defined behavior?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

annevk
annevk reviewed Dec 6, 2024
View reviewed changes

@annevk annevk left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

Wow, thanks for improving this! Overall this seems solid. I wouldn't mind us being a bit more opinionated here and there to guide implementations in a certain direction, but that can also be follow-up.

@farre can hopefully also make some time to review this.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread source Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread source Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread source Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread source Resolved

Uh oh!

There was an error while loading. Please reload this page.

@kjmcnee
Make named window lookup more precise and correct BCG swap logic
5a1b27e
In "the rules for choosing a navigable," the method to find an existing
navigable by name is vague. This updates the definition to accurately
reflect what the major implementations do. There are some differences
between implementations, so there remains in the spec some
optional/implementation-defined behaviour, but it's much narrower.
In particular, note that lookups are now explicitly scoped to
browsing context groups. The previous language in the named lookup
about "the user agent determines that the two browsing contexts are
related enough" is now no longer a part of the lookup logic, but a
consequence of the BCG swap decisions.

In "obtain a browsing context to use for a navigation response," the
existing spec only mentions COOP enforcement as a reason to do a
browsing context group swap. Some implementations perform a swap for
additional security and performance reasons. This is now reflected
in the spec.
@kjmcnee
kjmcnee force-pushed the bcg branch from 90cb46c to 5a1b27e Compare December 6, 2024 23:30
@kjmcnee
annevk review comments
283a9cf
@kjmcnee

kjmcnee commented Dec 10, 2024

Copy link
Copy Markdown
Contributor Author

do you think there are web platform tests we could write for this, despite the remaining implementation-defined behavior?

Yeah, there are some common behaviours that can be tested. I've sent you a CL here: https://chromium-review.googlesource.com/c/chromium/src/+/6081814

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@annevk annevk mentioned this pull request Dec 10, 2024
Force a browsing context group swap when navigating to and from file: URLs #10842
Open
@kjmcnee

kjmcnee commented Dec 10, 2024

Copy link
Copy Markdown
Contributor Author

Scheduling note: I'll be OOO from the 11th to January. If there are no issues, feel free to merge while I'm out.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Dec 10, 2024
@kjmcnee @chromium-wpt-export-bot
Add WPTs for named window lookup and BCG swap limits
aa5e57b
These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
@chromium-wpt-export-bot chromium-wpt-export-bot mentioned this pull request Dec 10, 2024
Add WPTs for named window lookup and BCG swap limits web-platform-tests/wpt#49631
Merged
aarongable pushed a commit to chromium/chromium that referenced this pull request Dec 11, 2024
@kjmcnee Chromium LUCI CQ
Add WPTs for named window lookup and BCG swap limits
1dd7436
These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Kevin McNee <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1394596}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Dec 11, 2024
@kjmcnee @chromium-wpt-export-bot
Add WPTs for named window lookup and BCG swap limits
0182295
These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Kevin McNee <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1394596}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Dec 11, 2024
@kjmcnee @chromium-wpt-export-bot
Add WPTs for named window lookup and BCG swap limits
1f7679a
These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Kevin McNee <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1394596}
domenic
domenic reviewed Dec 11, 2024
View reviewed changes

@domenic domenic left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

I did a more detailed review, and this is looking great. I guess we might have missed you, so we'll probably have to finish this ourselves, but if you're able to help, one thing that would be very nice would be a clearer documentation of the implementation-defined cases.

From what I can see we have the following:

  • sourceOrigin or destinationOrigin are non-HTTP(S), BCG swap is optional. #10842
  • "browser UI", BCG swap is optional. Part of #6356 although that's broader
  • BCG size is 1. The spec has clear notes about this one.
  • subtreesToSearch choice is either (top, window) or (top, ..., window). Can you give us more detail on why this is implementation-defined? Like, does Chromium choose differently depending on certain circumstances, and if so, which circumstances? Do you know what would motivate one choice or another?
  • Optionally check "allowed by sandboxing to navigate" (in two places). Why is this optional?
  • Implementation-defined order for searching through the BCG by name. This is pretty clear from the spec, but in the interest of maybe nailing this down in the future, can you tell us what Chromium picks?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread source Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread source Resolved

Uh oh!

There was an error while loading. Please reload this page.

@kjmcnee

kjmcnee commented Dec 11, 2024

Copy link
Copy Markdown
Contributor Author

I did a more detailed review, and this is looking great. I guess we might have missed you, so we'll probably have to finish this ourselves, but if you're able to help, one thing that would be very nice would be a clearer documentation of the implementation-defined cases.

Hi. I'm no longer at my work computer, but I can comment on the implementation differences.

  • subtreesToSearch choice is either (top, window) or (top, ..., window). Can you give us more detail on why this is implementation-defined? Like, does Chromium choose differently depending on certain circumstances, and if so, which circumstances? Do you know what would motivate one choice or another?

WebKit and Chromium search the requesting window's subtree then search from the top. Firefox iterates and searches from each ancestor. If there's a way to express in the spec that the implementation-defined behavior is fixed for the instance of the user agent, then that'd be appropriate here.

  • Optionally check "allowed by sandboxing to navigate" (in two places). Why is this optional?

Firefox and Chromium do this. WebKit does not. Similarly, the choice is fixed for the implementation.

  • Implementation-defined order for searching through the BCG by name. This is pretty clear from the spec, but in the interest of maybe nailing this down in the future, can you tell us what Chromium picks?

I can't remember the details, but I think Chromium and Firefox are based on creation order, or maybe reverse creation order. WebKit's ordering is arbitrary as it iterates over a hash set.

domenic reacted with heart emoji
All reactions
  • ❤️ 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This was referenced Dec 11, 2024
Window name targeting: which subtree to search is not interoperable #10848
Open
Window name targeting: checking "allowed by sandboxing to navigate" is not interoperable #10849
Open
Window name targeting: tie-breaking for same-named top-level traversables is not interoperable #10850
Open
@domenic

domenic commented Dec 11, 2024

Copy link
Copy Markdown
Member

Amazing, thank you so much Kevin.

I've filed follow-up issues for all of those. I will now push edits to the spec that take care of source formatting, and point to those follow-up issues. Then @annevk can review.

annevk reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

domenic added 3 commits December 11, 2024 15:52
@domenic
Add notes; source formatting
029e268
@domenic
Thread userInvolvement everywhere
ab5d2f5
This uncovered a couple places where it was missing
@domenic
Even more userInvolvement threading
c3ebf34
We named that parameter "userInvolvementForNavigateEvents" specifically because we left it null in cases where navigate events don't happen. But, there are cases where we need to consult user involvement for the BCG swap. So we need to thread it through more.

This is probably better anyways as it's more consistent.
@domenic domenic added interop Implementations are not interoperable with each other topic: frames/navigables/browsing contexts labels Dec 11, 2024
@domenic

domenic commented Dec 11, 2024

Copy link
Copy Markdown
Member

This is ready for review. I'd like @annevk or @domfarolino as additional reviewers, if possible, given the changes I made.

Almost all of them were related to threading the "user navigation involvement" through more thoroughly. Kevin's initial draft left it as the default of "none" in some cases (e.g. error pages) that implementations might care about, and it reused userInvolvementForNavigateEvents which was often set to null. I'm not sure if the latter cases actually overlap with cases where the UA would care, but it seemed better to fix it up. So a lot of changed lines are just related to that.

I'm also going OOO within the next day or two so any help getting this over the finish line is much appreciated.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

annevk
annevk approved these changes Dec 11, 2024
View reviewed changes
Comment thread source Outdated
picking a specific ordering, to achieve interoperability.</p>

<ol>
<li><p>If <var>currentTopLevelBrowsingContext</var> equals <var>topLevelBrowsingContext</var>,

@annevk annevk Dec 11, 2024

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

Nit: maybe this should use "is".

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@domenic
Nit fix
379e3c0
@domenic
domenic merged commit f23f559 into whatwg:main Dec 12, 2024
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Dec 13, 2024
@kjmcnee @moz-wptsync-bot
Bug 1936441 [wpt PR 49631] - Add WPTs for named window lookup and BCG…
94039b3
… swap limits, a=testonly

Automatic update from web-platform-tests
Add WPTs for named window lookup and BCG swap limits

These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Kevin McNee <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1394596}

--

wpt-commits: 1f7679ad01691ea3885537b8b19e1b88a0e7f152
wpt-pr: 49631
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Dec 16, 2024
@marco-c
Bug 1936441 [wpt PR 49631] - Add WPTs for named window lookup and BCG…
83b4ab2
… swap limits, a=testonly

Automatic update from web-platform-tests
Add WPTs for named window lookup and BCG swap limits

These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <domenicchromium.org>
Commit-Queue: Kevin McNee <mcneechromium.org>
Cr-Commit-Position: refs/heads/main{#1394596}

--

wpt-commits: 1f7679ad01691ea3885537b8b19e1b88a0e7f152
wpt-pr: 49631

UltraBlame original commit: 7c930d5bca8252fcec21396df3f9ecc6a7ae3e02
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Dec 16, 2024
@marco-c
Bug 1936441 [wpt PR 49631] - Add WPTs for named window lookup and BCG…
f194e62
… swap limits, a=testonly

Automatic update from web-platform-tests
Add WPTs for named window lookup and BCG swap limits

These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <domenicchromium.org>
Commit-Queue: Kevin McNee <mcneechromium.org>
Cr-Commit-Position: refs/heads/main{#1394596}

--

wpt-commits: 1f7679ad01691ea3885537b8b19e1b88a0e7f152
wpt-pr: 49631

UltraBlame original commit: 7c930d5bca8252fcec21396df3f9ecc6a7ae3e02
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Dec 16, 2024
@marco-c
Bug 1936441 [wpt PR 49631] - Add WPTs for named window lookup and BCG…
2bb21c7
… swap limits, a=testonly

Automatic update from web-platform-tests
Add WPTs for named window lookup and BCG swap limits

These tests verify the behaviour discussed here:
whatwg/html#10818

While there is some implementation defined behaviour, we can add tests
for the behaviour that's consistent between the major implementations,
namely that proactive browsing context group swaps can't be done while
another context exists in the group, that named lookups are scoped to
browsing context groups, and the lookup order in the case of multiple
contexts with the same name.

Bug: None
Change-Id: I515f527fb94a711bdd8eeb6610df2127571dcc3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081814
Reviewed-by: Domenic Denicola <domenicchromium.org>
Commit-Queue: Kevin McNee <mcneechromium.org>
Cr-Commit-Position: refs/heads/main{#1394596}

--

wpt-commits: 1f7679ad01691ea3885537b8b19e1b88a0e7f152
wpt-pr: 49631

UltraBlame original commit: 7c930d5bca8252fcec21396df3f9ecc6a7ae3e02
@kjmcnee
kjmcnee deleted the bcg branch January 2, 2025 23:06
@kjmcnee

kjmcnee commented Jan 2, 2025

Copy link
Copy Markdown
Contributor Author

Thanks for the help in getting this merged.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 5, 2025
@AtkinsSJ
LibWeb/HTML: Update Document::create_and_initialize() to latest spec
680e310
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 5, 2025
@AtkinsSJ
LibWeb/HTML: Update Navigable::choose_a_navigable() to latest spec
60266e3
This corresponds to part of whatwg/html#10818
@AtkinsSJ AtkinsSJ mentioned this pull request Jan 5, 2025
LibWeb/HTML: Update some navigables code to current spec LadybirdBrowser/ladybird#3151
Merged
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 7, 2025
@AtkinsSJ
LibWeb/HTML: Update Document::create_and_initialize() to latest spec
2ace499
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 7, 2025
@AtkinsSJ
LibWeb/HTML: Update Navigable::choose_a_navigable() to latest spec
5c56397
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 7, 2025
@AtkinsSJ
LibWeb/HTML: Update Document::create_and_initialize() to latest spec
ea5b57b
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 7, 2025
@AtkinsSJ
LibWeb/HTML: Update Navigable::choose_a_navigable() to latest spec
c946de4
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/html that referenced this pull request Jan 7, 2025
@AtkinsSJ
Editorial: Correct userNavigationInvolvement -> userInvolvement
34e6137
This was missed in whatwg#10818.
AtkinsSJ added a commit to AtkinsSJ/html that referenced this pull request Jan 7, 2025
@AtkinsSJ
Editorial: Correct userNavigationInvolvement -> userInvolvement
5962f21
This was missed in whatwg#10818.
@AtkinsSJ AtkinsSJ mentioned this pull request Jan 7, 2025
Editorial: Correct userNavigationInvolvement -> userInvolvement #10899
Merged
annevk pushed a commit that referenced this pull request Jan 7, 2025
@AtkinsSJ
Editorial: correct userNavigationInvolvement -> userInvolvement
d1c086a
This was missed in #10818.
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 7, 2025
@AtkinsSJ
LibWeb/HTML: Pass user_involvement through navigables code
c176e7f
This corresponds to part of whatwg/html#10818

Also corrected a typo, see whatwg/html#10899
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 7, 2025
@AtkinsSJ
LibWeb/HTML: Pass user_involvement through navigables code
57e5e21
This corresponds to part of whatwg/html#10818
@AtkinsSJ AtkinsSJ mentioned this pull request Jan 7, 2025
LibWeb: Bring navigables code closer to spec LadybirdBrowser/ladybird#3171
Merged
awesomekling pushed a commit to LadybirdBrowser/ladybird that referenced this pull request Jan 11, 2025
@AtkinsSJ @awesomekling
LibWeb/HTML: Pass user_involvement through navigables code
c6a18f7
This corresponds to part of whatwg/html#10818
pbrw pushed a commit to pbrw/ladybird that referenced this pull request Jan 14, 2025
@AtkinsSJ @pbrw
LibWeb/HTML: Pass user_involvement through navigables code
6cf0777
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 21, 2025
@AtkinsSJ
LibWeb/HTML: Update Document::create_and_initialize() to latest spec
452b69f
This corresponds to part of whatwg/html#10818
AtkinsSJ added a commit to AtkinsSJ/ladybird that referenced this pull request Jan 21, 2025
@AtkinsSJ
LibWeb/HTML: Update Navigable::choose_a_navigable() to latest spec
5f81338
This corresponds to part of whatwg/html#10818
kalenikaliaksandr pushed a commit to LadybirdBrowser/ladybird that referenced this pull request Jan 21, 2025
@AtkinsSJ @kalenikaliaksandr
LibWeb/HTML: Update Document::create_and_initialize() to latest spec
6f8d301
This corresponds to part of whatwg/html#10818
kalenikaliaksandr pushed a commit to LadybirdBrowser/ladybird that referenced this pull request Jan 21, 2025
@AtkinsSJ @kalenikaliaksandr
LibWeb/HTML: Update Navigable::choose_a_navigable() to latest spec
d40ccb9
This corresponds to part of whatwg/html#10818
Psychpsyo pushed a commit to Psychpsyo/ladybird that referenced this pull request Jan 23, 2025
@AtkinsSJ @Psychpsyo
LibWeb/HTML: Pass user_involvement through navigables code
d19ee6d
This corresponds to part of whatwg/html#10818
Psychpsyo pushed a commit to Psychpsyo/ladybird that referenced this pull request Jan 23, 2025
@AtkinsSJ @Psychpsyo
LibWeb/HTML: Update Document::create_and_initialize() to latest spec
a0bebbd
This corresponds to part of whatwg/html#10818
Psychpsyo pushed a commit to Psychpsyo/ladybird that referenced this pull request Jan 23, 2025
@AtkinsSJ @Psychpsyo
LibWeb/HTML: Update Navigable::choose_a_navigable() to latest spec
07bf827
This corresponds to part of whatwg/html#10818
lozy219 pushed a commit to lozy219/html that referenced this pull request Mar 10, 2025
@AtkinsSJ @lozy219
Editorial: correct userNavigationInvolvement -> userInvolvement
5cc695b
This was missed in whatwg#10818.
@coderabbitai coderabbitai Bot mentioned this pull request Aug 2, 2026
エディタが複数開かれた際に編集内容が初期化されてしまう不具合の修正 masanori-satake/QuickLog-Solo#527
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@domenic domenic domenic left review comments
@annevk annevk annevk approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

interop Implementations are not interoperable with each other topic: frames/navigables/browsing contexts

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Disowning owner should perhaps affect link targeting

Uh oh!

There was an error while loading. Please reload this page.

3 participants

@kjmcnee @domenic @annevk
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.