Issue 764252  has been merged into this issue.

I think peter@ summed up the challenges really well in https://bugs.chromium.org/p/chromium/issues/detail?id=764252#c1. There's a risk of creating an inconsistent experience, and a lot of edge cases.

raymes@ - do you have thoughts from the permissions perspective, particularly in the context of how WebAPK/Chrome permissions might overlap?

Personally I feel that we need a higher-level vision of the model we want to work toward with Add to Homescreen apps, otherwise we're going keep facing these types of questions with inconsistent answers (should X data be deleted, should Y permission be reset, should Z setting be shared).

I can only really see 2 consistent mental models though:
1) Add to homescreen is a shortcut into Chrome and data and settings are shared when the site is opened in Chrome or the App.
2) Add to homescreen is like an Android app and data and settings are not shared with Chrome

(1) Seems very preferable to me for many reasons, but it would mean that "uninstalling" the "app" should not revoke anything. 

It would be great to get agreement on whether we should do this or close as WontFix as per #4.1 .

In addition, I note Peter originally left open  Issue 764252 , which has since been merged into this issue, to address a specific other use case:

"the user *disables* notifications for the WebAPK and then uninstalls it. This will cause notifications to show up again [...] That's definitely not expected"

The fix for this use case would presumably be to share the 'blocked' permission with chrome when the user disables notifications for the web apk. (It's complicated by the fact that we don't get a callback when users disable notifications for an app at the system level, so this would actually have to be at the point where we first detect that notifications are off for the web apk.. -I doubt we'd have time to copy over the permission statuses at the point where the web apk is getting uninstalled). Which would mean going down the #4.1 route.

Maybe the discussion surrounding #4.1 and #4.2 has moved on since October which would help inform this decision. Does anyone know what the current thinking is? (I seem to remember a design doc floating around chrome-ui-review..)

I think we've headed slightly more toward (1) but owencm and sbirch might be able to provide more thoughts on where we're at. 

Sharing permission between the native app and Chrome might be tricky to get right but could be interesting to explore.

Assigning to Owen to advise on next steps here.