microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.4k stars 29.33k forks source link

Web: Mobile Safari support #85254

Open rebornix opened 4 years ago

rebornix commented 4 years ago

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

Bugs


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:

rebornix commented 4 years ago

Move this item to backlog as there are blockers that we want to track.

kieferrm commented 4 years ago

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.

IFrame issues

  1. 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.
  2. When switching apps and coming back to the browser tab that contains the codespace then the editor appears as having focus but does not receive any keyboard events.

Other issues

  1. When switching apps and coming back to the browser tab that contains the codespace, the codespace needs to reconnect.
  2. Scrolling inside the editor or any view neither works vertically nor horizontally, all scroll events are going to the browser.
  3. When having my sidebar on the left, I cannot grap the editor scrollbar on the right because it's covered by the native scrollbar.
  4. When having my sidebar on the right, trying to grab the scrollbar thumb with the mouse is hard. When I place the mouse in the middle of the scrollbar width then I grab the sash. The mouse pointer needs to be only halfway over the scrollbar.
  5. When working with the magic keyboard, every time the editor has focus the screen keyboard affordance comes up. Is there any way to avoid this from happening?
  6. We're using the native menus for dropdowns such as Terminal or Debugging.
  7. Only native Copy&Paste works which loses formatting information (and is non-trivial visually “read”). I also have to unbind the keyboard shortcuts to make that work with the keyboard.

Polish

  1. We should think about mimicking the native controls. I.e. the mouse pointer disappears in favor of a highlighted element.
kieferrm commented 4 years ago

@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.

rebornix commented 4 years ago

@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!

mjbvz commented 4 years ago

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

VincentDondain commented 4 years ago

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?

rebornix commented 4 years ago

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.

VincentDondain commented 4 years ago

@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/

alefragnani commented 4 years ago

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.

VincentDondain commented 4 years ago

@alefragnani I believe the trackpad issue is being tracked here: https://github.com/microsoft/vscode/issues/106232

alefragnani commented 4 years ago

@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

kieferrm commented 4 years ago

@rebornix pls see also https://github.com/github/codespaces/issues/1345

k8n commented 3 years ago

The upstream WebKit issue now appears fixed.