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:
- Escape. Escape key is the major key for hiding UI elements in the workbench. For native elements, iOS may know how to map
Ctrl+[ to behave the same as Escape, however for our keybinding service, we always check keyboard event, which doesn't understand Ctrl+[ at all.
- Function keys. Without Fn keys, quite a lot of our core features are not highly accessible: Command Palette (F1), Rename (F2), Next Match (F3), Next Reference (F4), Debug (F5, F9, F10, F11), Next Problem (F8), Go to Definition/Impl (F12), etc.
- Hover is missing. Definition/Implementation hovers in editor, View title bar actions, List View quick actions, etc rely on Hover events triggered from mouse move. They are hidden by default and only visible and actionable when hover happens (or sometimes even worse, hover with keyboard shortcuts). On a touch screen, these features are not accessible.
- Debug
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.
- Most UI elements are small. This is exacerbated by even the smallest mouse cursor being a rather large circle.
- Button/Checkbox/ActionbarItem are 10-20 px wide. It requires users to be very precise while acting on them.
- Default list view height is small and not customizable.
- Editor gutter consists of glyph area (we put breakpoints on it), line number and margin (we put folding icon on it) and users can easily mis-click/touch anyone of them.
- Sashes are thin and no indicator for clicking or dragging
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
wheelevent iPad OS trackpad scroll / mouse wheel support #106232 (upstream https://bugs.webkit.org/show_bug.cgi?id=210071 )cursor:styles Safari/iPadOS: UI affordance for non default cursor style #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.openonly 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.