FWIW, I tried a local release build of Chrome on Android and I can't repro.

I was worried that it was this change:
https://codereview.chromium.org/2884743002

But Grace mentioned that this just started happening yesterday :-/

I am wondering whether it is related to https://codereview.chromium.org/2829943002/#ps560001.

I think it is reverted in the trunk now.

Looks like it's back on.

Haven't been able to repro on ToT with clankium

I did get something like this just now with Chrome Dev. Note I'm on the public O beta and it actually was an ANR. vm traces attached but it doesn't look like a chrome issue as far as I can tell

Deleted: traces.txt 918 KB

traces.txt 918 KB View Download

Hmm, just got update to 61.0.3114.0, still can repro.

Yaron, can you see whether you can repro with Canary?

Assigning to Yaron, who said that he is working on this

I'm on the public android O beta and that chrome canary doesn't even list "add to homescreen" in the menu :/
Will have to try when in the office tomorrow with a build from the flashstation

Hmm, are you on the latest Canary? I have the issue with no "add to homescreen" for Beta. I thought Peter identified the issue and filed crbug/723811. But that bug marked as won't fix. Maybe Peter knows the current status.

Yes, same version as you

Hmm, after a fresh sync and building monochrome from Tot shows the same stuck situation.
Reverting piotrs CL didn't help, nor did Ted's. From a breakpoint, it seems like in some cases none of our tab observer methods for hiding the splashscreen are triggering

Actually, it may have just been that monochrome was running incredibly slowly. Local builds of it seem much slower than chrome

I actually think I've seen this type of hang when I launch Custom Tabs, so maybe this isn't limited to web apps/apks?  It seems like if I kill the custom tab (hit back) and click on the link again, it will load.  But like Yaron's comments in #12, #13, I don't know if it is just really slow to init and by the second click, the browser process has started up.

Interesting. So possibly we're doing something unique in init during ChromeTabbedActivity's startup
I still can't explain why monochrome seems so much slower for debug than chrome

Ted: are you using mononchrome in debug for testing? On a Pixel for local dev it seems unusably slow and mostly doesn't load pages (that's why I was seeing above behaviour)

It actually just seems like the first navigation never works in monochrome :/
I suspect the warmed up renderer is borked somehow
killing the renderer and reloading causes it to navigate or navigating elsewhere from omnibox works.

Ah ha...I don't use monochrome for testing, so that could definitely be why I don't see this.

Commenting out ChildProcessLauncher.warmUp(ContextUtils.getApplicationContext()); from AsyncInitTaskRunner.java fixes this for me. WebApks load and the first launch in chromium also works

Confirmed it's new in 60.0.3111.0
I suspect it's this change: https://chromium-review.googlesource.com/c/514424/
cause of 
 git log 0d764046b1e7ea6eb145e2aa39a88a6d0ac3e714..b1c5e931c5e329c64b70f484beb2320a221e5571 content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncher.java

but it doesn't revert cleanly. trying to understand it a bit better

I think the issue has to do with these line in logcat:

05-30 12:00:09.248 20720-20732/com.google.android.apps.chrome:sandboxed_process0 E/cr_ChildProcessService: Service has not been bound with bindToCaller()
05-30 12:00:09.252 20586-20719/com.google.android.apps.chrome D/cr_ChildProcLauncher: [ChildProcessLauncher.java:429] on connect callback, pid=-1

namely, we don't a correct handshake on setup and seemingly lose the pid when warmup connection is used. I still haven't conclusively confirmed it's that patch though but Jay volunteered to take a look

huh, that's not supposed to happen. monochrome doesn't set bindToCaller check:
https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/MonochromeApplication.java?rcl=f23174882c11f77a5b58cf37ab4051a2ad68a4bf&l=27

if jay is already looking, then I won't dig too deep then.

Oh, bug is here, oops:
https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncher.java?rcl=28f9bbec79ad97de51c4e99bb13359e1d691add0&l=59

Issue 727787 has been merged into this issue.

oh keyed off isExternal vs bindToCallerCheck?

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

commit 580410917ea90ebc1f040380a82d51392a6b88e6
Author: Jay Civelli <jcivelli@google.com>
Date: Wed May 31 05:21:17 2017

Fix for ChildProcessLauncher's warm-up connection.

My previous CL https://chromium-review.googlesource.com/c/514424/
change the warm-up connection erroneously to use
bindAsExternalService in place of bindToCallerCheck.
Fixing it and adding a test.

BUG= 726901 

Change-Id: I8b2dfc7ccc8dbf6db22af45714d7777c437e8f16
Reviewed-on: https://chromium-review.googlesource.com/518289
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Commit-Queue: Jay Civelli <jcivelli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475811}
[modify] https://crrev.com/580410917ea90ebc1f040380a82d51392a6b88e6/content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncher.java
[modify] https://crrev.com/580410917ea90ebc1f040380a82d51392a6b88e6/content/public/android/javatests/src/org/chromium/content/browser/ChildProcessLauncherTest.java

Need to fix m60 as well, which looks slightly different

Please note that this will need to be merged to M60 branch (3112) by 5PM PT today in order to get picked up for this week's Dev release.

Just out of a conference. Will do it now.

Fix landed on M60 branch

https://chromium-review.googlesource.com/c/520184/

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

commit 4affea92b3b772a2c30addb18fbe1fa7de893626
Author: Jay Civelli <jcivelli@google.com>
Date: Wed May 31 22:39:54 2017

[Merge to M60] Fix for ChildProcessLauncher's warm-up connection.

My previous CL https://chromium-review.googlesource.com/c/514424/
change the warm-up connection erroneously to use
bindAsExternalService in place of bindToCallerCheck.
Fixing it and adding a test.

BUG= 726901 

Change-Id: I8fcd1a743c8732c092233c1705bb82dde922be6d
Reviewed-on: https://chromium-review.googlesource.com/520184
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#68}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/4affea92b3b772a2c30addb18fbe1fa7de893626/content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncher.java
[modify] https://crrev.com/4affea92b3b772a2c30addb18fbe1fa7de893626/content/public/android/javatests/src/org/chromium/content/browser/ChildProcessLauncherTest.java

Works as per expected behavior as per C#0. Verified issue in Nexus5X/O on 60.0.3112.10

 Issue 727386  has been merged into this issue.

 Issue 728452  has been merged into this issue.