Lay out webview view after claim to avoid flash in wrong area#310204
Open
yogeshwaran-c wants to merge 1 commit intomicrosoft:mainfrom
Open
Lay out webview view after claim to avoid flash in wrong area#310204yogeshwaran-c wants to merge 1 commit intomicrosoft:mainfrom
yogeshwaran-c wants to merge 1 commit intomicrosoft:mainfrom
Conversation
When a webview view becomes visible, the overlay was claimed (which makes the underlying container visible) without an immediate layout pass. Because the overlay is absolutely positioned and reuses its DOM element across shows/hides, the container could become visible briefly at the coordinates left over from the previous layout. With panel alignment set to justify, this manifests as a one-frame flash of the webview in the panel area when toggling a sidebar webview view. Trigger an explicit layoutWebview() right after claiming so that the overlay is repositioned over the current view pane before the next paint. Fixes microsoft#243038
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
2 participants
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.
Fixes #243038
What
When a sidebar (or auxiliary bar) webview view is toggled while the panel alignment is set to
justify, the webview briefly flashes in the panel area before settling back into its correct location.Why
OverlayWebviewis absolutely positioned and reuses its DOM element across shows/hides.WebviewViewPane.updateTreeVisibility()callsclaim()to make the overlay container visible, but it does not trigger an immediate layout pass. The container therefore becomes visible at whatever coordinatesdoLayoutWebviewOverElementset the last time the overlay was laid out. When the workbench layout has changed in the interim (e.g. the panel was opened injustifyalignment, which shifts the bounding rect of the side bar), those stale coordinates can land in the panel area for a single frame, producing the observed flash. The next layout call (driven bylayoutBody/ the resize observer) then snaps the overlay back into the correct place.Fix
After
claim(), explicitly calllayoutWebview()so that the overlay is repositioned over the current view pane container before the next paint. This is guarded on_containerbeing set, so it is a no-op untilrenderBodyhas run. The existinglayoutBody-driven layout path still runs as before; this just ensures the very first paint after a claim uses up-to-date coordinates rather than the stale ones from the previous show.Risk
Very small. The change adds one extra synchronous
layoutWebviewOverElementcall on visibility transitions, which already happens on every resize. No behavior change when_containeris unset (initial construction), andrelease()continues to hide the overlay as before.