Re: [w3c/manifest] Privacy Review: handle start_url tracking (#399)

> Why not just have an installed web app that operates in its scope and when users click a link to another origin it opens in the user's web browser, like with other installed apps?

@npdoty @lknik as @benfrancis mentioned, while this seems simple on the surface, in practice, it breaks *lots* of behaviour in subtle ways because web content fundamentally assumes same-browsing-context navigation unless explicitly requested otherwise. Moving to a separate storage partition is effectively akin to spawning a new browsing context for out-of-scope links.

For OAuth, the auth correctly happens in a browser window, but the original web app either isn't refocused, or isn't passed the token it needs to confirm that auth has happened correctly since it's passed in POST, through XHR, or some other slightly unusual configuration that worked when everything was in the same browsing context (with the end result being that you're not authed in the web app).

This [doc](https://docs.google.com/document/d/1ZFItpUruPclnYechVkgXz9lVEwAK2Tuuo-592ohPpDo/edit#) collects a number of reported issues when Chrome previously implemented the link-opens-in-new-browsing-context behaviour. A couple of instructive (and lengthy) bug reports are [here](https://bugs.chromium.org/p/chromium/issues/detail?id=771984)  and [here](https://bugs.chromium.org/p/chromium/issues/detail?id=771418)

We tried playing whack-a-bug for a while here in Chrome on Android, but eventually it became clear that the correct thing to do was preserve the expected navigation behaviour - if a link is clicked and the developer or user hasn't requested that it open a new browsing context, stay in the current browsing context.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/399#issuecomment-635023036