The contents of our manifest.json file are (@ https://notify.tech/wp-content/plugins/onesignal-free-web-push-notifications/sdk_files/manifest.json.php?gcm_sender_id=57146562538):

{
  "name": "OneSignal WordPress Test Blog",
  "short_name": "OneSignal Test Blog",
  "icons": [
    {
      "src": "https://onesignal.com/images/notification_logo.png",
      "sizes": "144x144",
      "type": "image/png"
    }
  ],
  "start_url": "/",
  "display": "standalone",
  "gcm_sender_id": "57146562538",
  "gcm_user_visible_only": true
}

Retagging this as OS=Android, not OS=Mac.

Punting to dominick and pkotwicz who have been editing these files.

Jason, thanks for sending this in. :)

Regarding bug #1, this is a duplicate of  crbug.com/632462  which I fixed a few weeks ago and should be in Chrome 52 (as you note).

Regarding  bug #2 , this is due to one unfortunate limitation and an actual bug. The unfortunate limitation is that Android provides no way for us to know if a shortcut is or isn't still on the home screen. So we use a 10 day launch heuristic; if the site was launched from homescreen within the last 10 days, we assume it's still there and permit notification deep linking.

The bug is that the "clear site data" button actually doesn't clear the fact that the website was recently visited (this will be cleared if you use the overflow menu -> Settings -> Clear Browsing Data). I'll fix this so that the time is also cleared via the clear site data button.

Hey dominickn,

Thanks for the quick reply!

It does look like this issue was fixed in Chrome 52 (awesome!).

I did notice something else though (is this a bug / if so, should I open another issue for it?)

If the web app is not open, a notification that deep links to the web app does so successfully in Chrome 52 (opens the web app to the correct page).

However I noticed if the web app is already open to page A, and a notification deep links to page B, the web app does not navigate to page B; instead, the web app remains on page A. This behavior occurs both when the web app is a foreground task and background task. This behavior does not occur if the web app is killed, because then the notification deep links correctly. 

#6: this may be due to the way in which you're opening the notification. If you focus a window with client.focus() in your service worker, this will simply bring the existing window back to the front without navigating it to the URL (focus() doesn't do any navigation). To avoid this, you can either remove the .focus() call, or guard it with a conditional with checks that the url open in the client matches the url that you want to open. Does that make sense?

If you still find that there's any issue after checking that out, open a new bug with the Javascript code in your service worker and I'll take a look.

Thanks Dominick! That makes sense, we are calling client.focus().

>However I noticed if the web app is already open to page A, and a notification deep links to page B, the web app does not navigate to page B; instead, the web app remains on page A. This behavior occurs both when the web app is a foreground task and background task. This behavior does not occur if the web app is killed, because then the notification deep links correctly. 

I've noticed this on Chrome 55 too.
The way I'm opening the url is: 
`event.waitUntil(clients.openWindow(urlToOpen));`

I think our improved add to home screen fixes these deep linking issues since web apps are now proper Android APKs. Please re-open if you see more issues, thanks!