This isn't doesn't seem to be an issue with overview specifically. After following your steps, all accelerators seem to not work (fullscreen, alt-tab, brightness, etc.) but entering overview with 3 finger swipe on the track pad still works.

+afakhry to triage

I was able to repro.

There are multiple issues here:
-1- Browser windows don't have a minimum size for their contents. As a result, the minimum size of the browser view is calculated such that the window is just enough to contain (See attached screenshot):
  - frame, tabstrip, toolbar, and bookmark bar (if enabled) on a normal browser window.
  - just the frame caption buttons in an app browser window.

+pkasting@ and sky@ did we ever have a minimum size for the browser window that doesn't result in the contents being resized to 0?

-2- When the system settings window is resized such that the contents is 0x0, the RenderWidgetHostViewAura's window is set to invisible, as a result the focus is moved to it's parent in [1]. 
    - The Overview Mode accelerator works the first time because that parent window is visible. 
    - When we exit the Overview Mode, the focus manager attempts to RestoreFocusedView() [2] (which is a WebView in this case).
    - We end up setting the focus on the RenderWidgetHostViewAura's window which is already hidden.
    - Later event don't work at all (not even delivered to the AcceleratorController) as the event is not even dispatched because the target cannot accept events [3] because the window is not visible [4].


I think the issues we need to fix:
- In -1-, we should define a minimum size for window contents.
- In -2-, we shouldn't allow focus to be set on hidden windows.
- Also in -2-, I think accelerators should continue to be delivered to AcceleratorController even if the event target can't accept events? This seems like a regression and I suspect it's what causes  issue 855756  to happen sometimes. +jamescook, +oshima, and +sadrul if they know what could have regressed.


[1]: https://cs.chromium.org/chromium/src/ui/wm/core/focus_controller.cc?q=FocusController::OnWindowVisibilityChanged&sq=package:chromium&g=0&l=151
[2]: https://cs.chromium.org/chromium/src/ui/views/focus/focus_manager.cc?q=RestoreFocusedView&sq=package:chromium&g=0&l=436
[3]: https://cs.chromium.org/chromium/src/ui/events/event_dispatcher.cc?q=ProcessEvent&sq=package:chromium&g=0&l=117
[4]: https://cs.chromium.org/chromium/src/ui/aura/window.cc?q=Window::CanAcceptEvent&sq=package:chromium&g=0&l=1200

Deleted: Selection_096.jpg 44.3 KB

	Selection_096.jpg 44.3 KB View Download

Deleted: Selection_097.jpg 8.5 KB

	Selection_097.jpg 8.5 KB View Download

(1) No, but it seems reasonable, as long as the minimum is extremely small, e.g. 1x1.

I agree: if we focus invisible windows, then that is a bug. If we don't move focus away from a window when it becomes invisible, then that is also a bug.

Triggering accelerators for windows that can't accept events: perhaps? Without knowing what it is used for currently, it is difficult to say.

Re #7: using 1x1 as minimum size for contents fixes the issue of this bug, however isn't 1x1 too small?

Re #8: I tried changing Window::CanFocus() by adding a check for visibility after the first check for root winodws, essentially making it look like:

bool Window::CanFocus() const {
  if (IsRootWindow())
    return IsVisible();

  if (!IsVisible())
    return false;

  ....
}

This also fixes this problem, but reading this comment in [1] made me question this solution.

  // NOTE: as part of focusing the window the ActivationClient may make the
  // window visible (by way of making a hidden ancestor visible). For this
  // reason we can't check visibility here and assume the client is doing it.

[1]: https://cs.chromium.org/chromium/src/ui/aura/window.cc?q=Window::CanFocus&sq=package:chromium&g=0&l=585-587

The reason I worry about using a "more usable" minimum size is that (a) some web content may want to programmatically resize to a very small width/height (e.g. some of the old Chrome Experiments which would open lots of very small windows tiled near each other), and (b) IMO ideally Chrome would allow users to shrink things as small as we can go without introducing bugs, and let the user decide what they actually need.

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

commit 4ab66959410437e3d4e4e566ae096d56e9fdb06b
Author: Ahmed Fakhry <afakhry@google.com>
Date: Wed Jul 18 02:14:56 2018

Prevent a zero-sized browser contents

Allowing a browser window to be resized such that
the contents view's size is 0x0 caused the contents
view's window to become invisble and stop it from
being able to accept events.

Instead we use a minimum size of 1x1 for the contents.

BUG= 847179 

Change-Id: I7790d5e2e4862fce8bb19a5c7d3134b45c6a0c63
Reviewed-on: https://chromium-review.googlesource.com/1141344
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Ahmed Fakhry <afakhry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575907}
[modify] https://crrev.com/4ab66959410437e3d4e4e566ae096d56e9fdb06b/chrome/browser/ui/views/frame/browser_view_layout.cc

The issue reported in this bug doesn't happen anymore after the fix has landed. The remaining question is: Should we prevent invisible windows from receiving focus?

Filed issue 889321 to track the remaining question in #12. Closing this one.