New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 883414 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 13
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android , Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Link capturing not working as expected for login on alternate domain

Project Member Reported by petele@google.com, Sep 12

Issue description

Spotify 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



 
Labels: -OS-Mac OS-Android OS-Chrome
Cc: pkotw...@chromium.org ortuno@chromium.org yfried...@chromium.org mgiuca@chromium.org hanxi@chromium.org
Components: UI>Browser>WebAppInstalls Mobile>WebAPKs
+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).
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.
Status: WontFix (was: Unconfirmed)
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