Try using anchor positioning for webview#307758
Conversation
Fixes microsoft#307489 Not supported yet in all browsers so we still need the existing code too but I think should fix this caese
There was a problem hiding this comment.
Pull request overview
This PR attempts to fix mis-positioned webview content (e.g. markdown preview in Sessions) when the window is moved by leveraging CSS Anchor Positioning so the overlay webview tracks its editor anchor between explicit layout calls.
Changes:
- Add CSS Anchor Positioning setup/teardown when a webview is claimed (sets
anchor-nameon the editor host andposition-anchor/top/lefton the webview container). - Re-apply
top/left: anchor(...)afterlayoutWebviewOverElement(...)overwrites positioning with explicit pixel values. - Import
toDisposableto ensure the anchor-related inline styles are cleaned up with existing_webviewVisibleDisposables.
Show a summary per file
| File | Description |
|---|---|
| src/vs/workbench/contrib/webviewPanel/browser/webviewEditor.ts | Adds anchor-positioning-based tracking for overlay webview placement to better handle window moves. |
Copilot's findings
- Files reviewed: 1/1 changed files
- Comments generated: 2
| // Use CSS Anchor Positioning to automatically track position changes. | ||
| // The editor element's parent acts as the CSS anchor, and the webview | ||
| // container is tethered to it | ||
| if (this._element?.parentElement) { | ||
| const anchorName = `--${this._element.id}`; | ||
| this._element.parentElement.style.setProperty('anchor-name', anchorName); | ||
| const container = input.webview.container; | ||
| container.style.setProperty('position-anchor', anchorName); | ||
| container.style.setProperty('top', 'anchor(top)'); | ||
| container.style.setProperty('left', 'anchor(left)'); |
There was a problem hiding this comment.
The new anchor-positioning code sets top/left to anchor(...) unconditionally. In browsers that don’t support CSS Anchor Positioning, assigning an unsupported value clears the inline top/left that layoutWebviewOverElement(...) just computed (see OverlayWebview.doLayoutWebviewOverElement), which can regress positioning instead of preserving the existing fallback. Please add runtime feature detection (e.g. CSS.supports(...)) and only apply anchor-name / position-anchor / top: anchor(...) / left: anchor(...) when supported, including in the re-apply logic in synchronizeWebviewContainerDimensions.
|
|
||
|
|
There was a problem hiding this comment.
There are two consecutive blank lines here; please remove the extra whitespace to keep formatting consistent with the surrounding code.
mjbvz
changed the title
Fixes #307489
Not supported yet in all browsers so we still need the existing code too but I think should fix this case