Open rebornix opened 4 years ago
Move this item to backlog as there are blockers that we want to track.
The following comes from a short test-run with @rebornix of GH Codespaces in Safari on iPad. Some of the issues are caused by the VS Code WebUI being embedded in an iframe. This will change in the near future as we’ll move out of iFrame.
@grorg you mentioned on twitter you’d be interested in helping to improve the safari experience. 5, 6, 7, 9 seem that they could benefit from your help.
@grorg the first time when we tested iPadOS 13.4 we found that scrolling with trackpad doesn't work and we thought it's because we didn't handle the events correctly. Turns out to be that it's a bug in webkit (tracked as https://bugs.webkit.org/show_bug.cgi?id=210071 ) and currently with our virtual rendering, we can't workaround this issue. It would be great if this issue can be tackled, thanks in advance!
Hi @grorg, if you are still looking for webkit bugs effecting VS Code, this one came up recently: https://bugs.webkit.org/show_bug.cgi?id=215589 (it may be a duplicate)
This bug prevents out extension detail pages, which use webviews with script disabled, from showing in safari. I tried to work around it last iteration but ended up causing a regression. I'm going to try another approach this iteration but it would be great it the solution we use today worked in Safari as well
Hi,
The workbench is too big; the workbench resizes according to the size of the container which currently is the iframe, however once we are out of the iframe it seems we won't be able to get the minimized browser chrome or we size the workbench by the amount the minimized browser chrome is smaller than the regular one.
@rebornix, @kieferrm What is the ETA on moving away from using an iFrame? (edit: it looks like deiframing already shipped no?) To clarify, is your comment affecting the following?
Render workbench in visual viewport (to avoid being covered by on screen keyboard, or assistive editor)
I am still seeing the virtual keyboard overlaying the cursor on iPadOS.
Also, is this meta issue the place to track adding support for iPadOS 13.4 pointer interactions?
I am still seeing the virtual keyboard overlaying the cursor on iPadOS.
An embedder (e.g., codespace) needs to listen to viewport size change and then resize the vscode workbench.
Also, is this meta issue the place to track adding support for iPadOS 13.4
@VincentDondain can you help elaborate a bit on this one? I thought it's for UIKit but not Web elements.
@rebornix ok thanks for the info I'll check if we're resizing the workbench properly on our end (;
For the pointer interactions: I thought I read they added special features to WebKit/Safari but I think they're only saying use PointerEvents
which we hopefully already do.
For reference: https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/
Just to update that issues 4 and 5, commented in https://github.com/microsoft/vscode/issues/85254#issuecomment-626065078 remains not working on iPadOS 14.
In my tests, I’m using a regular bluetooth mouse, instead of a Trackpad.
@alefragnani I believe the trackpad issue is being tracked here: https://github.com/microsoft/vscode/issues/106232
@VincentDondain It appears to be. The only problem/misinformation that I see about that issue, it only describes about trackpad, not mouse wheel. The WebKit issue, on the other hand, talks about both.
I would ask you to update that issue, correctly describing it handles both scenarios.
Thank you
@rebornix pls see also https://github.com/github/codespaces/issues/1345
The upstream WebKit issue now appears fixed.
This is a meta issue for our Safari (on iOS/iPadOS) support (issue list) and this can be used to track the limitations and gaps we see today on mobile / touch screens.
updated Oct 2020.
To enable users to use the Web UI in Safari on iOS for some basic work, we need to fix the following blocking issues
Blockers
wheel
event https://github.com/microsoft/vscode/issues/106232 (upstream https://bugs.webkit.org/show_bug.cgi?id=210071 )cursor:
styles https://github.com/microsoft/vscode/issues/108832Bugs
With above items finished, users can use the Web UI for basic tasks if they us an external keyboard and mouse. However if you are not using an external keyboard with Escape and Function keys, or a mouse/pointer device, you can easily find the Web UI difficult to use and you can't be as productive as on the desktop. Major blockers are:
Ctrl+[
to behave the same as Escape, however for our keybinding service, we always check keyboard event, which doesn't understandCtrl+[
at all.Ctrl+[
to commands which used to be triggered byEscape
.window.open
only works if it's triggered from user click and synchronous. For debugging VS Code extension in the Web, it's silently broken as the window will not be opened without any error message.