This did happen once for me over the weekend. I have a theory that it occurs when the browser process has been evicted. We probably reinitialize history (cause getSavedInstanceState has data) and ignore the fact that there was a url override request.

Ya - WebappActivity.initializeUI looks wrong when in the context of a WebApk deep link. 

Great diagnosis yfriedman@!

BTW, it's happened a few more times for me since. One time at least the navigation was pretty quick, so I wonder whether the browser process was evicted in that case.

One thing I've noticed is that sometimes the navigations seem to go to a Twitter Lite tab running in my instance of Chrome Dev, and sometimes to the Chrome custom tab (?) for the Twitter Lite shortcut from my desktop. (The Twitter Lite PWA shows up as a separate app in the app switcher.) I don't think I explicitly opened a link to twitter.com in Chrome Dev, so wonder whether the notifications are targeting the right Chrome instance all the time.

Assigning this bug to ranj@ as this bug has the same fix as  Issue 696720 

When a non-null savedInstanceState is passed to Activity#onCreate() Activity#getIntent() is the intent that the WebAPK was originally created with, not the new intent 

I've observed the same behavior in current Chrome Beta (60) in a PWA I made[1]. When it's installed as WebAPK, clicking on notification only focuses the PWA, not opens the page requested.

This with openWindow(); method. Previously it was performing a navigate in WebAPK.

[1] https://m.omroepwest.nl

Sorry, failed to mention: it happens eight of the install and all the time, not after "some time".

pkotwicz: but that's still different from re-initing a WebApkInfo. Perhaps they could be solved with one patch but I think it's two different issues. For 696720, I imagine the WebApkInfo would be stored in memory merely between WebappLauncherActivity and WebApkActivity and not persisted for a long time which is different than how we init based on saved instance state.
Regardless, we should try and get this fixed in time for 61 whereas 696720 is just an optimizatino

I think that WebappLauncherActivity gets the new intent but that WebApkActivity gets the old intent

Oh interesting. I hadn't considered that. I would've thoguht it was gone cause it's excluded from history but it's possible so it'll need some investigation. Either way, I'm pretty sure we can repro this by opening the twitterlite wbapk, hitting home, adb shell kill com.google.android.apps.chrome and then launching a deeplink. Note that swiping away twitter lite won't work since that clobbers savedinstancestate. 

Yaron: I was able to repro the failure (which is why I know its root cause). I stupidly implemented (and wrote comments for) the wrong fix before finding out that the fix does not work

We have the same issues for webapps.
If:
1) Chrome is unexpectedly killed
2) The user had several webapps open
3) The user tries to launch a webapp from the homescreen
The wrong webapp might be launched

Is this really blocked by  issue 744843  or is it the same thing? Should we just dup them? 

kbr/nekr.fabula: a CL just landed this morning so I'm interested to hear on reproducibility with the next canary (presumably tomorrow) and dev caught from trunk (I think possibly the next one)

It's no blocking. I gonna submit a cl base on previous submitted one after.

nevermind #14, the cl was changed along the way so it was just preparing for the fix. :S still one CL to go..

That's OK. Please do ping this bug when the fix is in. I have been seeing this periodically, usually coinciding with long start times after tapping the notification, so may be able to confirm that it's reliably fixed within a few days.

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

commit 86578d527048a212767618e16ed461f80400ff8b
Author: Ran Ji <ranj@chromium.org>
Date: Mon Aug 14 16:16:02 2017

Fix not navigating to proper page when open from notifications in Twitter

Clean saved state if open from notification, otherwise WebApk will return
to previous opened page.

Bug:  739927 
Change-Id: Ic0c95a4a718aa137451f4bed5c7dd1fd9e4f3805
Reviewed-on: https://chromium-review.googlesource.com/612826
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Commit-Queue: Ran Ji <ranj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494064}
[modify] https://crrev.com/86578d527048a212767618e16ed461f80400ff8b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java

Ok, stay tuned for next canary/dev (assuming it's 62) :)

 Issue 755383  has been merged into this issue.

Marking this as fixed. Please re-open it if the issue still occurs.

Anecdotally I haven't seen this in latest dev push, curious if others are also seeing this behave better

Haven't run it long enough personally to tell for sure.

(I did see it happen again a couple of times last week before the fix above went to Dev.)