Dave recently wrote some good advice about what to do—and what not to do—when it comes to complaining about web browsers. I wrote something on this topic a little while back:
If there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it
To summarise Dave’s advice, avoid conspiracy theories and snark; stick to specifics instead.
It’s very good advice that I should heed (especially the bit about avoiding snark). In that spirit, I’d like to document what I think is a bug on iOS.
I don’t need to name the specific browser, because there is basically only one browser allowed on iOS. That’s not snark; that’s a statement of fact.
This bug involves navigating from a progressive web app that has been installed on your home screen to an external web view.
To illustrate the bug, I’ll use the example of The Session. If you want to recreate the bug, you’ll need to have an account on The Session. Let me know if you want to set up a temporary account—I can take care of deleting it afterwards.
Here are the steps:
- Navigate to thesession.org in Safari on an iOS device.
- Add the site to your home screen.
- Open the installed site from your home screen—it will launch in standalone mode.
- Log in with your username and password.
- Using the site menu, navigate to the links section of the site.
- Click on any external link.
- After the external link opens in a web view, tap on “Done” to close the web view.
Expected behaviour: you are returned to the page you were on with no change of state.
Actual behaviour: you are returned to the page you were on but you are logged out.
So the act of visiting an external link in a web view while in a progressive web app in standalone mode seems to cause a loss of cookie-based authentication.
This isn’t permanent. Clicking on any internal link restores the logged-in state.
It is surprising though. My mental model for opening an external link in a web view is that it sits “above” the progressive web app, which remains in stasis “behind” it. But the page must actually be reloading, either when the web view is opened or when the web view is closed. And that reload is behaving like a fetch event without credentials.
Anyway, that’s my bug report. It may already be listed somewhere on the WebKit Bugzilla but I lack the deductive skills to find it. I’m not even sure if that’s the right place for this kind of bug. It might be specific to the operating system rather than the rendering engine.
This isn’t a high priority bug, but it is one of those cumulatively annoying software paper cuts.
Hope this helps!
Top comments (0)