I have analyzed the problem, and I think I understood what is going on.

When recovering tabs from a previous session, SessionRestoreImpl::RestoreTabsToBrowser takes place. It is expected that it loads the last active tab in a first pass, and on a second pass, SessionRestoreImpl::FinishedTabCreation loads the rest of the tabs.

However, in the first pass it is also expected that WebContentsViewAura instances are created for every tab, and temporarily parented according to the aura::Window set in the call to WindowParentingClient (see aura::client::SetWindowParentingClient).

For chromeos/mash, the aura window tree looks like this, for 2 tabs being recovered:

1-       Unknown<-1> (0x34ff86f77160) bounds(0, 0, 746, 431) WindowVisible LayerVisible opacity=1,0
2-          WebContentsViewAura<-1> (0x34ff872d2840) bounds(0, 0, 746, 358) WindowHidden LayerHidden opacity=1,0
3-          WebContentsViewAura<-1> (0x34ff86fd0160) bounds(0, 0, 746, 358) WindowHidden LayerHidden opacity=1,0

The WebContentsViewAura corresponding to the last active tab, then, continues with the loading procedure, as expected. During the process it gets re-parented accordingly, so that the tree looks like this:

1-       Unknown<-1> (0x34ff86f77160) bounds(0, 0, 746, 431) WindowVisible LayerVisible opacity=1,0
2-         DesktopNativeWidgetAura - content window<-1> (0x34ff86f77000) bounds(0, 0, 746, 431) WindowHidden LayerHidden opacity=1,0
3-          NativeViewHostAuraClip<-1> (0x34ff8635d1e8) bounds(0, 73, 746, 358) WindowVisible LayerVisible opacity=1,0
4-            WebContentsViewAura<-1> (0x34ff872d2840) bounds(0, 0, 746, 358) WindowVisible LayerVisible opacity=1,0
5-              RenderWidgetHostViewAura<-1> (0x34ff872d2dc0) bounds(0, 0, 746, 358) WindowVisible LayerVisible opacity=1,0
6-        WebContentsViewAura<-1> (0x34ff86fd0160) bounds(0, 0, 746, 358) WindowHidden LayerHidden opacity=1,0

where:

* 1/Unknown is the WindowParentingClient aura::Window. 
* line 4 shows the WebContentsViewAura already re-parented, and with a valid RenderWidgetHostViewAura child, indicating the loading proceeded ok.
* line 6 still has a dummy WebContentsViewAura child of the WindowParentingClient aura::Window.

-----------------------
The problem starts here
-----------------------

WebContentsViewAura instances corresponding to other tabs (not the active one), should not be loaded in the first pass, but they do, because of the way the aura window tree is constructed.

All dummy WebContentsViewAura are child of the WindowParentingClient aura::Window, when it is set to visible, as part of the browser start up, it notifies all its observers, including the dummy WebContentsViewAura instances.

So this calls WebContentsViewAura::OnWindowVisibilityChanged on the non-active ones, which trigger navigation/loading for them.

  2 #1 0x55807d783999 content::WebContentsImpl::DidStartLoading()
  (...)
  9 #7 0x55807d461214 content::NavigationControllerImpl::NavigateToPendingEntry()
 10 #8 0x55807d777b4d content::WebContentsImpl::WasShown()
 10 #9 0x55807d7ctb00 content::WebContentsViewAura::OnWindowVisibilityChanged()
 11 #10 0x55807fb84ff6 aura::Window::NotifyWindowVisibilityChangedAtReceiver()
 12 #11 0x55807fb84da2 aura::Window::NotifyWindowVisibilityChangedDown()
 13 #12 0x55807fb82ac0 aura::Window::SetVisible()
 14 #13 0x55807fb828c8 aura::Window::Show()
 15 #14 0x5580826aa092 views::NativeViewHostAura::ShowWidget()
 16 #15 0x55808269d0ab views::NativeViewHost::Layout()
 17 #16 0x55808269cf06 views::NativeViewHost::Attach()
 18 #17 0x558080a80194 views::WebView::AttachWebContents()
 (...)
 26 #25 0x55808083cd8c chrome::AddRestoredTab()
 27 #26 0x55807e7a16f0 SessionRestoreImpl::RestoreTab()
 28 #27 0x55807e7a0273 SessionRestoreImpl::RestoreTabsToBrowser()
 29 #28 0x55807e79f85b SessionRestoreImpl::ProcessSession
 (...)

Down the road, SessionRestoreStatsCollector expects that only the last active tab is loaded in the first pass. But, as said above, in the case of mash, all tabs are loaded. When the tabs finish loading, the assert is hit.

NOTE: In chromeos/mus, it does not happen because the ::SetWindowParentingClient sets the window upper in Ash's window hierarchy tree, and dummy WebContentsViewAura instances, temporarily children of it, are not affected when the browser window is set to visible.

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

commit 284943d5dc070f507b5ffaacce110afc7411bf82
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Tue Aug 01 04:11:29 2017

Factor out some duplicated logic in SessionRestoreImpl::RestoreTabsToBrowser

The method SessionRestoreImpl::RestoreTabsToBrowser executes in two ways:

- user is recovering a previous session and creating a new browser session
for that.
- user is recovering a previous session and (re)using an existing browser
session for that.

Both paths have similar logic, with some peculiarities, that is now is shared
with this PR.

This is a preparation step to fix Bug 749506:
https://chromium-review.googlesource.com/c/593868/

TEST=no behavior change, so no new tests needed.

BUG=749506

Change-Id: I6974d24defb8681a7a2e736f1ee98861d9ee316b
Reviewed-on: https://chromium-review.googlesource.com/593867
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#490847}
[modify] https://crrev.com/284943d5dc070f507b5ffaacce110afc7411bf82/chrome/browser/sessions/session_restore.cc