vscode: bug positioning of webview in explorer
- VSCode Version: 1.51
- OS Version:macOS 10.6.7
Steps to Reproduce:
My extension have 4 view. just the second view is webview.
- expand the second view and the third view.
- expand and shrink the first view, the second view will be broken
Does this issue occur when all extensions are disabled?: Yes/No
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 14
- Comments: 19 (9 by maintainers)
I assume this is a typo… 😃 Where was it fixed - out of curiosity? (Self-referencing this issue)
@mjbvz - I was wondering if you had any ideas for how best to handle this?
The PR: #137506 is hacky but will fix this until a proper solution can be created.
I’m happy to help with a less hacky solution, either moving the iframe into a child of the view container, or animating the floating iframe, but would like to know which direction you would like to go in before committing time to it.
I encounters the same issue. This issue happens when at least one view expanded below current webview section. I also reproduced this issue using the vscode sample ‘webview-view-sample’. @mjbvz Do we have any plan to fix this?
Hi @mjbvz - I have created a PR with a temporary fix - it’s not pretty but will (from a user point of view) fix this until a better solution can be implemented.
I’m also happy to work on a proper fix for it, but think it is best to sync with you first and see if you have any opinions on the best approach. One option would be rather than having a floating iframe, to make the iframe a child of the view so it would inherit the position, rather than manually having to keep it positioned correctly. (This will probably have to wait until the new year though.)
I also see the issue on Windows.
I have added the following step to reproducing steps.
Version: 1.57.0-insider (user setup) Commit: a62df5d6c53e844bfdc50694f943c3f34b6ff50e Date: 2021-06-03T17:38:02.890Z Electron: 12.0.9 Chrome: 89.0.4389.128 Node.js: 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0.19042
I think he meant to say it was fixed by #137506 - although that PR was only really meant to be a workaround, and doesn’t fully solve the issue, so I’d be tempted to leave this issue open until we have a fully solution that respects the animation.
A quick summary of the main underlying issue and why it occurs only under specific conditions.
We have a ResizeObserver which checks when the webview parent changes size, and updates the overlay webview accordingly. During a normal reveal, this observer fires multiple times making the webview appear to move with the view below it.
However, it is possible, by a certain arrangement of panels, to have the view move, but not change size. In this case, the ResizeObserver never fires, which is what the patch in #137506 handles, forcing the position to be manually recalculated 200ms later after animations are complete. This does not give us a smooth animation, but does ensure the webview ends up in the right place at the end of the animation.
Unfortunately, there is no such thing as a native movement observer to fire when an element is moved. We could create one by polling and checking the bounding box, but I am not sure how expensive that would be.
Is there any improvement for this ? I also suffer the issue with webview in sidebar while I am trying to expand and collapse the view