Ok, I don't think this has anything to do with ChildProcessLauncher and is instead a bug in tab restore for FullScreenActivity.

Still trying to sort it out exactly, but in debug mode, I'm actually hitting an assert here: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java?q=%22+assert+creationState+!%3D+TabCreationState.FROZEN_ON_RESTORE%22+package:%5Echromium$&l=528

If I skip the assert, I get a hung renderer as in release builds.
This logic has long since been evicted from my memory but it seems like we think we can restore some history for the full-screen tab but then fail to do so and end up in an inconsistent state
+twellington,dfalcantara

+peconn@ - this seems like it could be related to the picture-in-picture work for Android O that moved fullscreen web content to a new Activity.

Hmm, I think I'm onto something.
WebappDirectoryManager.findStaleWebappDirectories.
It seems to be nuking WebApk history files cause they're similar (but different) from Webapp. They're close enough that it looks like it's processing them, but it's really not and ends up deleting valid history elements. We just missed this while making webapks work cause there wasn't enough usage to see this history problem.

So the simplest fix is to change WebApkConstants.WEBAPK_ID_PREFIX from "webapk:" to "webapk-". This is because WebappDirectoryManager gets the intent's host while looking for live apps and using "webapk:..." means that the host is always "webapk". Not sure if there's any reason not to do this, but some local testing seems to check out.

Of course that entails being able to migrate over existing shared prefs from one place to the other (e.g. webapp_webapk:org.chromium.webapk.a4b4240ee93f1a289.xml ->webapp_webapk-org.chromium.webapk.a4b4240ee93f1a289.xml) :S

Xi pointed out yesterday that WebappDataStorage does not have any critical data for WebAPKs. WebappDataStorage mostly has timestamps that we use to determine when to next update WebAPKs. We wouldn't be sad if we lost all of the data in WebappDataStorage. However, we would need to ensure that we delete data in the old WebappDataStorage

> However, we would need to ensure that we delete data in the old WebappDataStorage

Don't these automatically age out after some period of time?

WebappRegistry.unregisterOldWebapps will already clear unused storage after 28 days but that's for webapps. For webapks, it just checks whether it's installed and both entries would map to an installed webapk.
At the end of the day though, it's a tiny amount of on-disk storage. Each webapk is <1k of shared prefs

I have a patch that CQ seems happy with up at https://codereview.chromium.org/2952023002/#msg3 but I still want to add tests

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

commit 5ff213a88961f80fab0e21a871b62eb4336f3cb0
Author: yfriedman <yfriedman@chromium.org>
Date: Mon Jun 26 14:21:32 2017

Change WebApk app-id prefix from 'webapk:' to 'webapk-'

This fixes some code which uses the host of a WebApp for various processing.
Specifically, when examining history state
(https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappDirectoryManager.java?type=cs&q=liveWebapps.add+package:%5Echromium$&l=111)
this would fail because 'webapk:' becomes the host name.

This also makes WebApk id's consistent with traditional A2HS ids.
Finally, this includes a change to the cleanup routine run on WebApps to age out the old entries.
We will lose install source as part of this but it's just metrics book-keeping for us and doesn't affect users.
BUG= 735060 , 735722 

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

[modify] https://crrev.com/5ff213a88961f80fab0e21a871b62eb4336f3cb0/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappRegistry.java
[modify] https://crrev.com/5ff213a88961f80fab0e21a871b62eb4336f3cb0/chrome/android/javatests/src/org/chromium/chrome/browser/webapps/WebappDirectoryManagerTest.java
[modify] https://crrev.com/5ff213a88961f80fab0e21a871b62eb4336f3cb0/chrome/android/junit/src/org/chromium/chrome/browser/webapps/WebappRegistryTest.java
[modify] https://crrev.com/5ff213a88961f80fab0e21a871b62eb4336f3cb0/chrome/android/webapk/libs/common/src/org/chromium/webapk/lib/common/WebApkConstants.java

Haven't heard any issues on this and it's been working for me on dev chanel

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

So the issue here is if a user opesn multiple wbapks, then chrome goes to the background and is evicted from memory. When user relaunches chrome, if/when they try a second webapk, they'll be stuck on the splashcreen forever cause the page isn't initialized. WOrkaroudn is to hit back or home and try again.

Spoke with yfriedman@ offline on this, the breakage is pretty bad when it does occur and the code only affects WebAPKs - thus approved for M60 branch 3112.

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

commit 8b2a6269e945ebf038f2377f3637b044deff6aa1
Author: Yaron Friedman <yfriedman@chromium.org>
Date: Mon Jul 10 17:26:56 2017

Change WebApk app-id prefix from 'webapk:' to 'webapk-'

This fixes some code which uses the host of a WebApp for various processing.
Specifically, when examining history state
(https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappDirectoryManager.java?type=cs&q=liveWebapps.add+package:%5Echromium$&l=111)
this would fail because 'webapk:' becomes the host name.

This also makes WebApk id's consistent with traditional A2HS ids.
Finally, this includes a change to the cleanup routine run on WebApps to age out the old entries.
We will lose install source as part of this but it's just metrics book-keeping for us and doesn't affect users.
BUG= 735060 , 735722 
TBR=pkotwicz

(cherry picked from commit 5ff213a88961f80fab0e21a871b62eb4336f3cb0)

Review-Url: https://codereview.chromium.org/2952023002
Cr-Original-Commit-Position: refs/heads/master@{#482267}
Change-Id: Ib52aea4f06752504b697f9d2e81ad22ec65c0be7
Reviewed-on: https://chromium-review.googlesource.com/565463
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#558}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/8b2a6269e945ebf038f2377f3637b044deff6aa1/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappRegistry.java
[modify] https://crrev.com/8b2a6269e945ebf038f2377f3637b044deff6aa1/chrome/android/javatests/src/org/chromium/chrome/browser/webapps/WebappDirectoryManagerTest.java
[modify] https://crrev.com/8b2a6269e945ebf038f2377f3637b044deff6aa1/chrome/android/junit/src/org/chromium/chrome/browser/webapps/WebappRegistryTest.java
[modify] https://crrev.com/8b2a6269e945ebf038f2377f3637b044deff6aa1/chrome/android/webapk/libs/common/src/org/chromium/webapk/lib/common/WebApkConstants.java