White bar appears when using external keyboard on iPad

[noisymime]

Does this issue occur when all extensions are disabled?: Yes

• Device: iPad Pro
• code-server: v4.4.0
• VSCode: 1.66.2

Steps to Reproduce: Using an iPad with external keyboard, selecting an area that allows keyboard input causes a white bar to appear at the bottom of the screen:

This is similar to #122390, though I am running a version after that fix has been added. This occurs in both PWA mode and regular Safari. Problem does not appear when using the in-built keyboard

The bar disappears when the keyboard is not active/usable.

[TylerLeonhardt]

Yes this seems to have occurred after Apple went from a full bottom bar to this hovering bar at the bottom.

I think we probably want to stretch VS Code too the very bottom (thus having some of it behind the hovering iPad bar). I'm a bit concerned that then the floating bar will be in the way... but that seems to be the canonical approach on iPad.

[cschoenecker]

Same bug, very annoying

[cschoenecker]

https://user-images.githubusercontent.com/21053090/169988203-94ea6574-c285-42cb-9906-e24211f13386.mp4

Even with the floating shortcut in the corner

[figuerascarlos]

You can go to Settings > General> Keyboards and disable shortcuts. with this workaround you can get rid of that annoying floating button, and vscode works perfectly.

[TylerLeonhardt]

I'm marking this as help wanted in case someone wants to investigate this. I have a feeling some magic will need to be added around here similar to what was there before: https://github.com/microsoft/vscode/commit/dbed1fbe954fdd34b05deeb273198d4f539a6173

Not sure how other websites handle this.

[cschoenecker]

You can go to Settings > General> Keyboards and disable shortcuts. with this workaround you can get rid of that annoying floating button, and vscode works perfectly.

Yes thanks, I discover this workaround but we have to disable “Shortcut” and the second above option on iPadOS 15 to hide the keyboard shortcut :)

[vultuk]

You can go to Settings > General> Keyboards and disable shortcuts. with this workaround you can get rid of that annoying floating button, and vscode works perfectly.

Unfortunately this also means that scrolling with a trackpad or mouse no longer works.

Interestingly I just had a check and the shorcut issue does not happen on Github Codespaces, the shortcut bar is there, but there's no white space.

[cthos]

I noticed this on Codespaces too, but it does appear if you switch tabs and return to the Codespace (though it does disappear if you subsequently reload the window).

[icharle]

You can go to Settings > General> Keyboards and disable shortcuts. with this workaround you can get rid of that annoying floating button, and vscode works perfectly.

Unfortunately this also means that scrolling with a trackpad or mouse no longer works.

Interestingly I just had a check and the shorcut issue does not happen on Github Codespaces, the shortcut bar is there, but there's no white space.

I had the same problem, disable shortcuts would cause that scrolling no works. it isn't look like a perfect solution.

[TylerLeonhardt]

I opened an issue on WebKit as this appears to be on them to fix since visualViewport isn't what I would have expected: https://bugs.webkit.org/show_bug.cgi?id=247410

[fosron]

+1 on scrolling not working on iPad Air with external keyboard

[filiptronicek]

Hey there @TylerLeonhardt 👋! Have there been any updates on your side with this issue? It still seems to happen in both Gitpod and https://github.com/coder/code-server, but I could not reproduce in Codespaces or https://github.dev.

[TylerLeonhardt]

I was always waiting on a WebKit fix... doesn't look like there's any traction in that issue. I'll see if there's anything we can on our end to push for a fix...

but you bring up a good point... how did they fix that? 😆

Let me ask them and see if I can get to the bottom of that.

[TylerLeonhardt]

Looked at this with @osortega and I think I know why this is happening. Looking here:

https://github.com/microsoft/vscode/blob/5e805b79fcb6ba4c2d23712967df89a089da575b/src/vs/base/browser/dom.ts#L291-L299

this is called with the workbench's parent here.

In vscode.dev, the workbench's parent is body, so it goes to that second if:

But in github.dev, the workbench's parent is this other div so it goes to the first if:

Well that changes the behavior of getClientArea using element.clientHeight instead of window.visualViewport.height.

The clientHeight of that random div is the correct value. Walking up the dom, we see:

• <div id=​"serverless-workbench" style=​"height:​ 100%;​">​ so height: 100%
• <div class=​"vsonline-serverless-workbench">​ which has an interesting:

  .vsonline-serverless-workbench {
  position: absolute;
  left: 0;
  top: 0;
  right: 0;
  bottom: 0;
  z-index: 3;
  }

• <div id=​"js-vscode-workbench">​ that has nothing interesting
• <body class="mac web"> has the same stuff as the body of vscode.dev
• <html> nothing interesting

So that's what is happening and why... now the question is how should it be fixed.

[TylerLeonhardt]

Ok so github.dev's solution works, but it has the following two problems:

1. status bar is covered by home indicator:
2. on screen keyboard doesn't cause a resize:
   • So you might not know where you are typing
   • and you can't see the status bar or terminal

Because of these points, I actually think the vscode.dev experience is better despite the big white bar. So I think that a solution for the WebKit bug is absolutely the right way forward to fix this bug. Only that, will achieve the best result of:

• height will be right above the height of the home indicator so it doesn't cover the status bar
• height will dynamically change if the on-screen keyboard shows up

vscode.dev could probably do a better job of honoring the theme color... so at least instead of white, it's the same color as the editor or something...

[filiptronicek]

Many thanks to you both for digging into this, @TylerLeonhardt, your findings have been incredibly helpful.

Agreed the github.dev's solution is not ideal either. Let's hope Apple moves with the WebKit bug soon!

[kevin-king]

Because of these points, I actually think the vscode.dev experience is better despite the big white bar.

The permanent white bar is significantly worse UX IMO than a line over the status bar or the virtual keyboard covering. One reason is that the white bar affects users at all times whereas using the on-screen keyboard is less impactful since users almost certainly have a hardware keyboard plugged in when using vscode and can still scroll the text above the virtual keyboard.

Screen real estate on iPad devices is additionally hindered by this bug https://github.com/coder/code-server/issues/3203 (upstream issue) where you lose text selection capabilities in full-screen mode and thus can't use the full view width-wise either.

From my testing, the experience is a lot better if we use innerHeight on iPad by simply removing this conditional:

 // If visual view port exits and it's on mobile, it should be used instead of window innerWidth / innerHeight, or document.body.clientWidth / document.body.clientHeight 
 if (platform.isIOS && window.visualViewport) { 
    return new Dimension(window.visualViewport.width, window.visualViewport.height); 
 } 

so that we fall into

// Try innerWidth / innerHeight
if (window.innerWidth && window.innerHeight) {
    return new Dimension(window.innerWidth, window.innerHeight);
}

[kjswanson]

Long time lurker first time poster.

I have side stepped the issue by using code-server v4.12.0. I start the code-server pwa on the ipad and then drag it to the external screen. This has been working for a couple of weeks now.

Hope this information gives someone in the “know” a good lead on the issue.

[halfama]

Still no solution for that ?