This looks like a the focus controller is null and during shutdown.

I was in this code recently, I'll take a look.

+oshima/sammiequon - any suggestions?

On ToT (30dd6e1152d5fd19daf365751e9e4133142195bc r623714) on linux-chromeos I can reproduce a similar looking DCHECK failure:

ninja -C out/Default -j 1000 -l 80 chrome && out/Default/chrome --ash-debug-shortcuts --ash-dev-shortcuts --ash-host-window-bounds="1280+0-1024x768" --user-data-dir=/tmp/udd --enable-features=SingleProcessMash

[228406:228406:0117/092820.451684:FATAL:window_util.cc(62)] Check failed: window->GetRootWindow(). 
#0 0x7fac9b95de5f base::debug::StackTrace::StackTrace()
#1 0x7fac9b88c13a logging::LogMessage::~LogMessage()
#2 0x7fac945fad33 wm::ActivateWindow()
#3 0x7fac94d59375 ash::WindowSelector::Shutdown()
#4 0x7fac94d5dca3 ash::WindowSelectorController::OnSelectionEnded()
#5 0x7fac94d563e1 ash::WindowGrid::OnWindowDestroying()
#6 0x7fac96c0cc58 aura::Window::~Window()
#7 0x7fac96c0d5de aura::Window::~Window()
#8 0x7fac8aa1b8aa ws::WindowTree::RemoveWindowFromKnownWindows()
#9 0x7fac8aa1f43d ws::WindowTree::DeleteWindowImpl()
#10 0x7fac8aa244bf ws::WindowTree::DeleteWindow()
#11 0x7fac8aa3da52 ws::mojom::WindowTreeStubDispatch::Accept()
#12 0x7fac9bc22636 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#13 0x7fac9bc21fc6 mojo::FilterChain::Accept()
#14 0x7fac9bc239a5 mojo::InterfaceEndpointClient::HandleIncomingMessage()

It only happens in release-with-dchecks. I can't get it to happen in debug. It's probably timing related.

Note the bug report is at 73.0.3669.0 (r622247), which is before my shutdown cleanup CL r622874. However, I suspect my shutdown CL didn't change things, since I get the failure above on ToT.

My guess is that SingleProcessMash is causing a window to get destroyed later than in classic, perhaps triggering OnWindowDestroying() after overview mode is partially shut down.

The DCHECK is in this code:

void ActivateWindow(aura::Window* window) {
  DCHECK(window);
  DCHECK(window->GetRootWindow());  <<<<<< here
  GetActivationClient(window->GetRootWindow())->ActivateWindow(window);
}

called from:

void WindowSelector::ResetFocusRestoreWindow(bool focus) {
  if (!restore_focus_window_)
    return;
  if (focus) {
    base::AutoReset<bool> restoring_focus(&ignore_activations_, true);
    wm::ActivateWindow(restore_focus_window_);
  }
...

I also wonder if we're destroying an aura window that has been detached from the parent hierarchy.

I hit the DCHECK if either the Gallery app or the Files app is the last window to close in overview.

More minimal repro:
* Start with one browser window open
* Open the Files app
* Enter tablet mode
* Hit overview button
* Close the browser
* Close the Files app

In this case there aren't any windows left, so I don't think there's a window to restore focus to. I'm surprised restore_focus_window_ isn't reset.

I think this is due to the order windowobserver is added.

Will this work?

* Make WindowGrid not a WindowObserver
* Notify OnWindowDestroying on WindowGrid in WindowSelector::OnWindowDestroying
  after restore_focus_window_ is reset.

I agree this looks like an observer order problem.

That's a little tricky, because WindowGrid observes multiple windows, and WindowGrid implements both OnWindowDestroying() and OnWindowBoundsChanged().

WDYT of making WindowSelector::Shutdown() call ResetFocusRestoreWindow(false) if there are no remaining items?

  ResetFocusRestoreWindow(remaining_items > 0 &&
                          enter_exit_overview_type_ ==
                              EnterExitOverviewType::kNormal);

this seems to fix the problem.

It ends up being a bit more subtle - it's not exactly an observer order problem, it's a difference in how SingleProcessMash triggers aura::WindowObserver notifications between parents and children.

I have a different fix at https://chromium-review.googlesource.com/c/chromium/src/+/1419361/

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

commit 43baa6d116c72d5da7b7c6580497627d50e86425
Author: James Cook <jamescook@chromium.org>
Date: Fri Jan 18 03:03:22 2019

SingleProcessMash: Fix crash when exiting overview mode with focused app

Overview mode caches the focused aura window when the user enters the
mode. It tries to restore focus to that window on exit.

However, the user might exit overview by closing the last top-level
window. That window might have a child that used to have focus.
For example, if the last open window is a app window, focus might have
been on that app's web contents.

SingleProcessMash uses the async window service code path to close
client windows (i.e. windows created by browser code). This means that
windows are disconnected from their parents first, then deleted.

Don't try to restore focus to an unparented window, because ash won't
be able to look up the focus controller, and the window is being torn
down anyway.

Bug:  922293 
Test: added to ash_unittests
Change-Id: I8d3a6e48566970fc4c282d8f7d3e74c602383ce8
Reviewed-on: https://chromium-review.googlesource.com/c/1419361
Commit-Queue: James Cook <jamescook@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623977}
[modify] https://crrev.com/43baa6d116c72d5da7b7c6580497627d50e86425/ash/wm/overview/window_selector.cc
[modify] https://crrev.com/43baa6d116c72d5da7b7c6580497627d50e86425/ash/wm/overview/window_selector_unittest.cc