In case you didn't know, DEV is installable as a PWA in Chrome and other browsers which support it. The new Microsoft Edge even has it as a + prompt, as such:
Functionally it works pretty well, but external links that do not have the target=_blank attribute (which is most links on DEV), open in an awkward in-app pseudobrowser with no navigation.
How should we handle this "correctly".
Should we add target=_blank to all outbound links? We could do this dynamically for PWA only. But is there a different "correct" way to do this?
Another desktop app, like Slack, would not open external links within the app. They would open in a browser. So that is probably the appropriate choice, but I'm not totally sure.
Thoughts?
Latest comments (25)
I am trying to open my external link inreal browser instead in-app browser. How to do it?
The in-app fake browser thing is a plague. Wherever I see this pattern used, it seems like it's designed to trap users within an app's ecosystem rather than to benefit the user (WeChat is one of the worst culprits for this). It's a real shame that PWAs have this default, leaving "don't screw your users over" as an opt-in behavior for developers to implement.
How about mobile app like workflow. Capture link click, open a dialog (open in browser [x cancel][- yes]. And let user be incharge of what they want to do. But it also depends on type of app. One app I was working on, was just electron version of a web based service. In that, we blocked all the links which were not internal navigation related. Even though there were some external link available on the browser access of app.
How does one use this PWA? Does it offer anything more than the website?
If it's basically just the website in its own frame then I don't mind what it does, but if adding targets to links affects the way the website works, then I'm against it.
wait. It looks like the website opens external links in new targets already. I'm against that, then!
Absolutely a new window, unless it's tied to maybe another dev.to subdomain like testing.dev.to codecamp.dev.to etc..
Once a target is out of your domain, offload it.. not even thinking about from a security standpoint, but in any work flow type situation, a new window is most appropriate, I don't want to lose a resource on one app at the cost of a new asset, basically.
Technically you could do it the other way only in case of PWA.
Set target blank as default for anchor tag.
<head>
<base target="_blank">
</head>
Add
target=selfto all internal/dev.to links.Great point about ad blockers.
Yep, definitely adding
rel="noopener noreferrer"alongside"target=_blank"though I'm not sure those same vulnerabilities would apply to PWAs. Seems like that should be somewhat of a firewall between the two. I'd be curious about whether that vulnerability persists.It's not just adblockers, there's a lot of functionality missing, like having to log in again to something your browser normally handles or syncing your history with another device.
Critically for me, I'd miss being able to bookmark something once I find it. Everything linked to from within the fake browser is lost forever unless you take a screenshot or remember what steps you took to get there.
As others have said, I like the "pseudo-browser". It is a familiar pattern for Android/Chrome users.
Some apps on Android have the option to open external links in the app or in the external browser, having that choice is a nice feature. But I'm not sure if there is a solution for PWAs to do that easily. Adding a user option may require appending
target=_blankto add external links if they have it set to open in an external browser as you mentioned.But the problem with the integrated popup browser is work flow is interrupted, as you can't cross reference both tabs, as this is blocking everything before it. It's limited in scope,.... But it is enough of an issue, especially for this crowd, where more tabs or windows are a much better option in most instances...
But the user always has the option to open that link in a new tab/window, via context menu or middle click. Using
target=_blankforces the choice on the user.EDIT: Also, I think the webview itself has a context menu to open the link in the browser.
Good tip, I can confirm that I get the following in Chrome on Windows.
It seems like the way it functions now does allow for full control.
Edit: Looks like the update to add
target="_blank"was made, so the default behavior is an external browser window. 🙁On the desktop, as a user, I prefer the external link to be opened on my default browser. Just as Slack works, for example.
On mobile, as a user, I prefer the in-app browser with the option to open on my default browser (I'm quite sure dev.to for iOS already works this way).
As a user I prefer the "in-app pseudobrower" solution.