Link capturing not working as expected for login on alternate domain |
|||
Issue descriptionSpotify authenticates users on a different domain from their PWA, once the user has logged in, they're not returned to the installed PWA. What steps will reproduce the problem? 1. Open https://authexp-pwa.glitch.me/ in browser (ChromeOS or Android) 2. Click "Install PWA" button, 3. Open as installed PWA, click Login link 4. Browser window opens (or CCT on Android), click login What is the expected result? Android: CCT should close and return to installed PWA experience ChromeOS: Browser window should close, and installed PWA should get focus again What happens instead of that? Android: CCT remains open ChromeOS: Browser tab closes, but browser retains focus. See code for this repo at: PWA: https://glitch.com/edit/#!/authexp-pwa?path=index.html Login: https://glitch.com/edit/#!/authexp-login?path=index.html
,
Sep 12
+cc some relevant folks. I'll see if I can find time today to dig into what's going on for Android at least. On Chrome OS, this will be fixed when we actually implement CCTs (which is planned).
,
Sep 13
I don't think CCTs would help here. The flow on the repro page is a bit strange. When clicking "Login", the page just navigates away. On Android, this doesn't create a new context i.e. Chrome just navigates the page to the target URL and shows some extra UI. Since there is no extra context being created, window.close() would just close the whole app. So there are two solutions on Android: 1. On authexp-pwa side, rather than navigating away, use window.open(). Then Chrome will create an extra context, which can call window.close() to go back to the original context. Site with the change: https://rhinestone-dresser.glitch.me/ https://glitch.com/edit/#!/rhinestone-dresser?path=index.html:90:56 2. On the authexp-login side, rather than calling window.close() just navigate back to https://authexp-pwa.glitch.me/ again. Site with the change: https://vanilla-office.glitch.me/ https://glitch.com/edit/#!/vanilla-office?path=index.html:1:0 There are some subtle differences between (1) and (2). For example, in (1) the page is still active in the background and there is clear "opening a new context" animation. In (2), the page is no longer active in the background and there is no clear animation to indicate that a new context was created. Solution (1) will work today on Desktop as well. Solution (2) won't work on desktop until we implement CCTs.
,
Sep 13
Gio is correct. I'll just add to what he said (since we both started responding in parallel): Rule of thumb: if it works in a normal browser, it should work in a PWA. This doesn't actually work in a normal browser tab. Here's what happens if you do that: 1. Open https://authexp-pwa.glitch.me/ in browser (ChromeOS or Android) 2. Click Login link. 3. The same tab navigates to the login page. Click login. The call to window.close() on the authexp-login side won't do anything (window.close() isn't allowed to close a window that wasn't opened by window.open()). This site seems designed *only* to work in PWAs under Chrome's old link capturing rules (which are broken). We are trying to move PWAs so that navigation works just the same as in a browser tab. Note that Solution (2) won't work in any "standards-compliant" PWA browser, including Chrome on Desktop, because this is actually specified behaviour in the manifest spec: https://github.com/w3c/manifest/issues/646 However, I'm planning to address this in Chrome regardless (see Issue 883564 ), and am working on a fix to the manifest spec in #646 above. Marking WontFix, but please follow Issue 883564 for updates. |
|||
►
Sign in to add a comment |
|||
Comment 1 by petele@chromium.org
, Sep 12