Tom, can you find the right owner?

I'm not very familiar with the onscreen keyboard, but why should it stay open? It seems to me like it should close, assuming it comes back if and when the user focuses another textfield.

The description isn't clear so let me clarify. There are actually two scenarios, one with sticky and another one with non sticky:

* With sticky mode, you can switch the selected window using VK in the list, but you can't finalize the selection. The window list stays on the screen, and clicking the item doesn't select the window.

* With non sticky mode, keyboard closes when you typed alt-tab once, so you can't use VK to select window. The window list stays on the screen, and clicking the item doesn't select the window.

Only way to recover from this state was to type alt-tab on real keyboard. It's not critical, but it did leave the desktop in weird state.

Are you still able to perform a single alt+tab? the UI is not supposed to display with virtual keyboard because you can't hold down two keys at once. So window switched functionality should just be between current window and MRU.

The keyboard should not close though.

You can press two keys at once with VK. Note that this is A11Y VK, which works as a real keyboard replacement.

Sorry what I mean is you can't hold down one key and then repeatedly press another key (which brings up the UI). My understanding is you can press Alt, then Tab and you'll switch to MRU window. Then you can repeat and go back to the original but you cannot Alt + Tab + Tab to MRU -1 window. Overview mode would be the best place to go for that for the A11y VK case

After speaking with lpalmaro, this is WAI. If you navigate to a UI with no text field then the VK should close

You probably haven't read my comment #4, and/or never tried this your self. Please do so.

I'm fine if UX decision is not to use switcher with VK, but current behavior is broken and should not be WAI.

My apologies, I see now the distinction you're making. This is the same bug as one I just reported. I'll copy over the helpful specifics you listed

 Issue 639027  has been merged into this issue.

reversing the direction of the dupe as this bug has more context and is older.

I took a few minutes to look at this and I am unclear what the ideal solution would be.

> With sticky mode, you can switch the selected window using VK in the list, but you can't finalize the selection. The window list stays on the screen, and clicking the item doesn't select the window.

This is because the virtual keyboard doesn't send events for modifiers key presses (or releases). (I tracked this down to [1].) This seems like it has the potential to break a lot of stuff since it doesn't behave the way a real keyboard behaves. I am tempted to say the fix belongs in the virtual keyboard itself, but maybe there's a good reason we don't send events for Alt and other modifiers?

> With non sticky mode, keyboard closes when you typed alt-tab once, so you can't use VK to select window. The window list stays on the screen, and clicking the item doesn't select the window.

You can re-open the keyboard by pressing the tray icon again, but then you run into the same problem as above.

===========

Possible solutions:
1) make virtual keyboard send events for modifier keystrokes (might fix other keyboard related bugs, like interacting with a webpage that expects these keystrokes to be reported)
2) make Alt+Tab UI respond to mouse/touch events
3) ignore alt+tab that comes from a virtual keyboard.

I like (3) if it's easy to do because I think using alt+tab on a virtual keyboard is never going to be the best way to switch windows. If we lived in a world where the only keyboard were the onscreen keyboard, I'm pretty sure we'd never have bothered with the Alt+Tab UI (or ui-less shortcut). If you are using your touchscreen (or pointer) to simulate a keyboard, why not just use your touchscreen (or pointer) to select the window you want? You can also use overview mode if you have a lot of windows. This suggests option (4), where virtual keyboard Alt+Tab just launches overview mode.

[1] https://cs.chromium.org/chromium/src/third_party/google_input_tools/src/chrome/os/inputview/controller.js?rcl=0&l=1372

Thanks for digging in Evan. 

I think 3) makes sense - but how hard would it be for a single Alt+Tab, no UI to still be possible?

Also there is no overview mode button in virtual keyboard.

>  how hard would it be for a single Alt+Tab, no UI to still be possible?

That would require solution #1, i.e. fixing the keyboard.

I discussed with tbuckley@ - lets do 3)

Note that status area is hidden when VK is visible, so you can't access overview mode icon when VK11 sticky mode is in use in Tablet mode. You have to hide the keyboard first. Just FYI:

re #15
Yah. When a11y VK is enabled, mouse interaction is expected instead of a touch screen. And in order to support modifier key combination, these keys need to be toggleable as user can't use mouse to press multiple modifier keys at once. That is probably why a11y VK is different from physical keyboard in terms of modifier key event sequence.
Sorry, I haven't work on Chromebook for a long time due to adb issue. So this might be a silly quesiton. But what was the reason that click failed to select window? Was it because window list doesnt expect click event?

> And in order to support modifier key combination, these keys need to be 
> toggleable as user can't use mouse to press multiple modifier keys at once.

Not sure I follow. The keys are toggleable, but why not send a key down when they're toggled to the on state and key up when toggled to the off state?

> But what was the reason that click failed to select window? Was it because 
> window list doesnt expect click event?

Because there's no reason to support pointer interaction with this UI, it's essentially just visual feedback for a keyboard shortcut. In any case the vk/alt+tab interaction would still be broken if alt+tab did accept mouse inputs. The only difference would be that it would be a little easier to get out of the broken state.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/252dbee7b15f43aa53242b68eb1bc41b272eaf26

commit 252dbee7b15f43aa53242b68eb1bc41b272eaf26
Author: estade <estade@chromium.org>
Date: Fri Aug 26 16:46:05 2016

Refuse to show Alt+Tab UI concurrently with virtual keyboard.

Overview mode is probably more useful to people who are trying to use
a touch screen. Simply no-op on Alt+Tab when the virtual
keyboard's showing.

BUG= 638269 

Review-Url: https://codereview.chromium.org/2256283003
Cr-Commit-Position: refs/heads/master@{#414731}

[modify] https://crrev.com/252dbee7b15f43aa53242b68eb1bc41b272eaf26/ash/common/accelerators/accelerator_controller.cc
[modify] https://crrev.com/252dbee7b15f43aa53242b68eb1bc41b272eaf26/chrome/browser/extensions/api/virtual_keyboard_private/chrome_virtual_keyboard_delegate.cc
[modify] https://crrev.com/252dbee7b15f43aa53242b68eb1bc41b272eaf26/ui/base/accelerators/accelerator.cc

Your change meets the bar and is auto-approved for M54 (branch: 2840)

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0406017868c50bd136a3495591f707a16293f443

commit 0406017868c50bd136a3495591f707a16293f443
Author: Evan Stade <estade@chromium.org>
Date: Thu Sep 01 21:19:04 2016

Refuse to show Alt+Tab UI concurrently with virtual keyboard.

Overview mode is probably more useful to people who are trying to use
a touch screen. Simply no-op on Alt+Tab when the virtual
keyboard's showing.

BUG= 638269 

Review-Url: https://codereview.chromium.org/2256283003
Cr-Commit-Position: refs/heads/master@{#414731}
(cherry picked from commit 252dbee7b15f43aa53242b68eb1bc41b272eaf26)

Review URL: https://codereview.chromium.org/2301873003 .

Cr-Commit-Position: refs/branch-heads/2840@{#107}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0406017868c50bd136a3495591f707a16293f443/ash/common/accelerators/accelerator_controller.cc
[modify] https://crrev.com/0406017868c50bd136a3495591f707a16293f443/chrome/browser/extensions/api/virtual_keyboard_private/chrome_virtual_keyboard_delegate.cc
[modify] https://crrev.com/0406017868c50bd136a3495591f707a16293f443/ui/base/accelerators/accelerator.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0406017868c50bd136a3495591f707a16293f443

commit 0406017868c50bd136a3495591f707a16293f443
Author: Evan Stade <estade@chromium.org>
Date: Thu Sep 01 21:19:04 2016

Refuse to show Alt+Tab UI concurrently with virtual keyboard.

Overview mode is probably more useful to people who are trying to use
a touch screen. Simply no-op on Alt+Tab when the virtual
keyboard's showing.

BUG= 638269 

Review-Url: https://codereview.chromium.org/2256283003
Cr-Commit-Position: refs/heads/master@{#414731}
(cherry picked from commit 252dbee7b15f43aa53242b68eb1bc41b272eaf26)

Review URL: https://codereview.chromium.org/2301873003 .

Cr-Commit-Position: refs/branch-heads/2840@{#107}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0406017868c50bd136a3495591f707a16293f443/ash/common/accelerators/accelerator_controller.cc
[modify] https://crrev.com/0406017868c50bd136a3495591f707a16293f443/chrome/browser/extensions/api/virtual_keyboard_private/chrome_virtual_keyboard_delegate.cc
[modify] https://crrev.com/0406017868c50bd136a3495591f707a16293f443/ui/base/accelerators/accelerator.cc

This bug isn't fixed on 56.0.2924.12 and 57.0.2945.0. In the above CL, "input.ime.sendKeyEvents" api which is used by virtual keyboard wasn't fixed. I'm not sure how to fix this now. Just marking all events from this api as EF_IS_SYNTHESIZED doesn't work due to InputMethodEventFilter (as described in the comment in the CL).

I'm not sure how to trigger the input.ime.sendKeyEvents api to send alt+tab, but we can just remove the synthesized checks as was originally intended in the above CL.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e97a4d2564c7ff2c4419164a119ec3d2424f7420

commit e97a4d2564c7ff2c4419164a119ec3d2424f7420
Author: estade <estade@chromium.org>
Date: Tue Jan 10 00:08:16 2017

Don't mark virtual keyboard events as synthesized or distinguish between
synthesized and non for Alt+Tab events.

This fixes a DCHECK in input_method_chromeos.cc and perhaps Alt+Tab's
interaction with input.ime.sendKeyEvents.

BUG= 638269 

Review-Url: https://codereview.chromium.org/2604093003
Cr-Commit-Position: refs/heads/master@{#442409}

[modify] https://crrev.com/e97a4d2564c7ff2c4419164a119ec3d2424f7420/ash/common/accelerators/accelerator_controller.cc
[modify] https://crrev.com/e97a4d2564c7ff2c4419164a119ec3d2424f7420/chrome/browser/extensions/api/virtual_keyboard_private/chrome_virtual_keyboard_delegate.cc

fixed hopefully, but I don't actually know how to test. Could you please verify, yhanada@?

I confirmed it's fixed. Thanks!

 Issue 627241  has been merged into this issue.

AS per #34