Issue metadata
Sign in to add a comment
|
alt-tab cycling stops at fullscreen windows
Reported by
gsf...@gmail.com,
Jun 22 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 8459.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2768.0 Safari/537.36 Platform: 8459.0.0 (Official Build) dev-channel samus Steps to reproduce the problem: 1. open more than two windows 1. fullscreen at least one window 2. alt-tab to cycle between windows What is the expected behavior? All windows are cycled in the usual alt-tab behavior. What went wrong? At fullscreen windows the alt-tab stops cycling as if the held-down alt key is not recognized. Did this work before? Yes maybe introduced by Issue 340339 Chrome version: 53.0.2768.0 Channel: dev OS Version: 8459.0.0 Flash Version: Shockwave Flash 22.0 r0
,
Jul 8 2016
Seems more like an issue with UI>Shell>Immersive unless alt-tab always involves OverviewMode.
,
Jul 8 2016
Can confirm, this has been broken for a while on dev channel and is becoming quite annoying. It also happens when you full-screen open-as-window apps, so it might not just be related to immersive mode. Issue 340339 really sounds like a likely culprit, the timeframe seems right.
,
Jul 9 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 15 2016
This hasn't been touched in over a month and has now cycled into beta channel. Do we really not care about breakages of basic features that have been working for years reaching stable?
,
Aug 15 2016
,
Aug 15 2016
I have a patch which fixes this, writing a test for this is proving difficult though.
,
Aug 15 2016
Issue 637071 has been merged into this issue.
,
Aug 16 2016
I found out why I couldn't test this in ash_unittests, we rely on the browser to forward the accelerator after it decides the fullscreen window is not going to handle the event. I've updated the test to simply verify the event will be passed onto the browser and uploaded my fix in https://codereview.chromium.org/2252673002
,
Aug 17 2016
flackr@ do you need approval to merge to M53 cros?
,
Aug 17 2016
Yes, this is broken in M53 and marked a release blocker so this would need to be merged back, but it's not landed yet.
,
Aug 17 2016
From crbug.com/637071 having the #ash-enable-window-cycle-ui flag enabled fixes the issue. Can we merge back the new ui?
,
Aug 17 2016
#12, I would not go as far as merging Alt+Tab in M-53 and certainly not because of this issue. I think we can bake it some more in Dev and Beta channels.
,
Aug 17 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/66b4142cfaf0acc038f220b6288089f8a60b923d commit 66b4142cfaf0acc038f220b6288089f8a60b923d Author: flackr <flackr@chromium.org> Date: Wed Aug 17 19:54:27 2016 Don't handle the tab press event in the window cycle event filter. Because fullscreen windows are allowed to handle alt+tab, we have to be careful not to handle the tab press event in the window cycle event filter as it will be treated as a fullscreen window preventing alt-tabbing. BUG= 622396 TEST=WindowCycleControllerTest.TabPastFullscreenWindow,WindowCycleControllerTest.TabKeyNotLeaked Review-Url: https://codereview.chromium.org/2252673002 Cr-Commit-Position: refs/heads/master@{#412616} [modify] https://crrev.com/66b4142cfaf0acc038f220b6288089f8a60b923d/ash/wm/window_cycle_controller_unittest.cc [modify] https://crrev.com/66b4142cfaf0acc038f220b6288089f8a60b923d/ash/wm/window_cycle_event_filter_aura.cc
,
Aug 18 2016
As far as I can tell there is no disable flag for the new UI, Evan is that correct? In which case we can't really test this on canary but I have manually tested this on a local build on M53. Adding merge requested.
,
Aug 18 2016
correct, no way to test on canary
,
Aug 18 2016
Your change meets the bar and is auto-approved for M53 (branch: 2785)
,
Aug 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cc813d84d461f08d853e621a1fda109bfe78060e commit cc813d84d461f08d853e621a1fda109bfe78060e Author: Robert Flack <flackr@chromium.org> Date: Sat Aug 20 03:16:19 2016 Don't handle the tab press event in the window cycle event filter. Because fullscreen windows are allowed to handle alt+tab, we have to be careful not to handle the tab press event in the window cycle event filter as it will be treated as a fullscreen window preventing alt-tabbing. BUG= 622396 TEST=WindowCycleControllerTest.TabPastFullscreenWindow,WindowCycleControllerTest.TabKeyNotLeaked TBR=varkha@chromium.org Review-Url: https://codereview.chromium.org/2252673002 Cr-Commit-Position: refs/heads/master@{#412616} (cherry picked from commit 66b4142cfaf0acc038f220b6288089f8a60b923d) Review URL: https://codereview.chromium.org/2260973003 . Cr-Commit-Position: refs/branch-heads/2785@{#692} Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382} [modify] https://crrev.com/cc813d84d461f08d853e621a1fda109bfe78060e/ash/wm/window_cycle_controller.cc [modify] https://crrev.com/cc813d84d461f08d853e621a1fda109bfe78060e/ash/wm/window_cycle_controller_unittest.cc
,
Aug 22 2016
,
Sep 19 2016
Chrome OS version 53.0.2785.128/8530.89.0 samus |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by abodenha@chromium.org
, Jun 23 2016Owner: varkha@chromium.org
Status: Assigned (was: Unconfirmed)