constellation: Track top-level pipeline changes in webviews#43013
Merged
delan merged 1 commit intoservo:mainfrom Mar 6, 2026
Merged
constellation: Track top-level pipeline changes in webviews#43013delan merged 1 commit intoservo:mainfrom
delan merged 1 commit intoservo:mainfrom
Conversation
c0fb60c to
65d9ffe
Compare
mrobinson
reviewed
Mar 6, 2026
Co-authored-by: Alice Boxhall <[email protected]> Signed-off-by: delan azabani <[email protected]>
bb2c6bd to
6074622
Compare
github-merge-queue bot
pushed a commit
that referenced
this pull request
Mar 26, 2026
in #43029, we defined an accessibility tree for each webview. we create those trees when accessibility is activated for that webview, then the embedder can graft it into their main accessibility tree. at the time, this accessibility tree was empty, but we ultimately want it to contain the accessibility tree of the documents loaded in the webview at any given time. to do that, we need to graft the active top-level pipeline’s accessibility tree into the webview accessibility tree. we should be able to ignore nested documents inside iframes here, and leave it to their parent documents to graft those in as part of layout accessibility. this patch hooks into the moment in the constellation where we detect that the top-level document has changed (#43013), and notifies libservo of the new AccessKit TreeId for the webview-to-pipeline graft node. this moment covers navigating to a new top-level document and navigating back or forward, but not the initial document loaded in the webview, so we also hook into the moment a ConstellationWebView is created, and do the same for that initial document. now the accessibility tree for a webview with accessibility activated should look like this: - embedder’s main tree - graft node for webview tree → webview tree - ~~graft node for document back in history~~ - graft node for active top-level document → (nothing yet) - ~~graft node for document forward in history~~ Testing: this patch updates the relevant accessibility test in libservo Fixes: part of #4344, extracted from our work in #42338 --------- Signed-off-by: Alice Boxhall <[email protected]> Signed-off-by: delan azabani <[email protected]> Co-authored-by: Alice Boxhall <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
whenever a browsing context loads a new document or otherwise navigates, the constellation sends a new frame tree to the compositor, giving us a nice, relatively central way to detect when we may need to update the graft node in a webview’s AccessKit subtree. but we only want to update that graft node when the pipeline in its top-level browsing context has changed, not just when the pipeline in any of its browsing contexts has changed.
this patch adds a field to the ConstellationWebView that tracks the active top-level pipeline for each webview, allowing us to check when a set_frame_tree_for_webview() call actually involves navigation in the top-level browsing context.
Testing: will be covered by accessibility tree tests in a later patch
Fixes: part of #4344, extracted from our work in #42338