I'm not able to get a repo on this but will keep trying. WebAPK folks, can you lend a hand? This probably is window focusing code somehow.

I can't repo it neither. I tested on Android N & O, both Chrome Beta and ToT.

@Matt: can you verify that whether this issue is still available?

@rbyers you said you experienced this issue. Can you confirm? (I have never seen it, but I use Chrome Stable on my Android device.)

Yes, I can still repro on Chrome 65 (beta) after uninstalling and reinstalling the Twitter light WebAPK.  Any traces or logs you'd like me to collect?

@rbyers: how do you install the Twitter light WebAPK? Do you install it from "Add to homescreen" menu in Chrome? Or you install the "Twitter lite" from Play store?

"Add to homescreen"

That is really strange. It would be great if you can answer the following questions:

- Do you have any other twitter app installed from Play store? I can reproduce the bug after I install another twitter lite.

- Which kind of notification that you got? Is it a message? 

- Does it only happen on a phone with multiple profiles?

- What is the android version? 

- Do you have any other twitter app installed from Play store? I can reproduce the bug after I install another twitter lite.

I have the full "Twitter" from the play store, but no Twitter Lite

- Which kind of notification that you got? Is it a message? 

I believe it's all types.  Just verified with a DM notification and a "liked" notification.

- Does it only happen on a phone with multiple profiles?

I don't know - I've only seen it on my phone.  Maybe ask the other people on Twitter who were complaining about whether they had multiple profiles or not?

- What is the android version? 

8.1.0 OPM1.171019.021

Thanks Rick! We have seen the same issue with Maps Go WeAPK before. Once you have a native version installed, PackageManager#queryIntentActivities(intent, ...) doesn't return the package name of the WebAPK at all. In other words, Chrome doesn't find the twitter WebAPK when the notification comes, and just handle the notification by iteself. You will also see "Site Setting" in the notification, but we have removed that from any WebAPK's notification. 

Unfortunately, we don't have any good solution to fix it yet. Mark it as WontFix, and feel free to reopen it.

The only issue re: #10 is whether this is a new issue. Xi: do you know that it's the verified intent that we're hitting? In #2, peter mentioned they changed focusing code and that has broken us in the past.

Have you confirmed that it's the code in ServiceTabLauncher that's failing to find the webapk?

This isn't a new issue. In the NotificationPlatformBridge#displayNotification(), the query of WebAPK package name via WebApkValidator.queryWebApkPackage(scopeUrl)   returns null.

Xi: that would cause the notification to appear to be originating from chrome. I think this is actually ServiceTabLauncher which chooses how to launch the notification. It could be the same issue but when I was poking at it with Rick yesterday, if he removed everything and then reinstalled webapk and native app it worked. I guess the open question was whether the twitter app had already configured its verified intent handler. Rick: can you repro today?

After the native app has been installed for awhile it stopped working.

If twitter changed something that caused this to break, then while not ideal it seems OK to me.  I'm still worried however that it's actually a regression.

I was just about to claim that I know it was working fine a few weeks ago, then remembered: I switched my twitter light from my "work" profile (where I have Chrome dev installed) to my normal profile (where I have Chrome beta installed).  So in the past I guess I had Twitter and Twitter light installed into different profiles, which I guess would mask this problem, right?

Can you run this:
adb shell dumpsys package domain-preferred-apps

and see if twitter shows up?

Yes, different android sign-in profiles (not accounts within a profile) would mask this

Yes, it's even listed twice:

  Package: com.twitter.android
  Domains: twitter.com www.twitter.com mobile.twitter.com ads.twitter.com
  Status:  always : 200000000

  Package: com.twitter.android
  Domains: twitter.com www.twitter.com mobile.twitter.com ads.twitter.com
  Status:  always : 200000013

Weird.
Regardless, I don't know when app link verification actually takes place but I know it doesn't have to happen instantly and given that you saw this break after some time and you have app links, it does confirm Xi's theory.

Ok, one last question to confirm something: before you click, what application is associated with the notification? Twitter Lite or Chrome? If it's the former, we can probably fix this quickly. If it's the latter, it's more involved.

The notification says "Chrome Beta - mobile.twitter.com" before I click on it.  I'll try uninstalling the native app and see if the notifications then show up differently.

Cool - thanks for confirming. So this is indeed what Xi suggested. Having the native app installed affects notification attribution. It's fixable but non-trivial basically because when we ask android who can handle the intent it "lies" (by design) and only says the native app can. So we need to work around it by seeing if the webapk is installed and can handle it.

We want to avoid having to scan all installed apps when we get a notification. When you use the webapk, we do store some shared prefs data about it. So what we could do is on receiving a notification, check whether a recently launched webapk scope matches, then call https://cs.chromium.org/chromium/src/chrome/android/webapk/libs/client/src/org/chromium/webapk/lib/client/WebApkValidator.java?q=webapkvalidator&sq=package:chromium&l=97 to confirm it's valid/still installed with Android and then delegate the notification.

I still think this is lower priority because (1) it's not broken and (2) you have to have the native and pwa installed which seems like an atypical user interaction?