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?
Top comments (25)
I don't know about "correct", but as a user I would personally prefer external links to open in the browser rather than within the PWA.
+1 for this
If I'm opening a specific app (like Slack), I want that app... no more.
If I want the browser, I will open it and browse other websites.
I agree with that. I even when it opens in app I choose open in chrome option.
I agree. I like it better, when external links open in a browser.
Agreed, but some sort of pop up to make sure you want to leave the app would be 👍
Does this maybe help?
developer.mozilla.org/en-US/docs/W...
I believe that is more for defining the scope of the PWA guidelines within the application. Basically instructing the browser not to run service workers etc. outside of the defined scope.
And if it means otherwise, I'm not sure how to get it to work. 😄
Since asking this question, I'm starting to think that the expected behavior really should be open in the browser. That way you can keep your DEV context, especially in the case of /connect etc.
But isn't this exactly what you asked?
"If the user navigates outside the scope, it returns to a normal web page inside a browser tab/window."
So you define the scope in the manifest.json and shouldn't even need to add target="_blank" to links.
Based on the information on developers.google.com/web/fundamen... it appears that you do need to add
target="_blank"I do see where the confusion came from on the MDN docs. Initially I read it the same way you did.
Hmmm perhaps, but implementations may vary. It seems like it still opens another browser page within the app or something. I think it's possible that this detail is not part of the spec. In fact, I think iOS had a the "back to browser" behavior by default and then switch to "in-app browser".
@ Tyler, awesome. That is the confirmation I was looking for and hadn't found. This makes it pretty clear what the current behavior is and that it is the expected behavior going forward.
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. 🙁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.
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!
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.
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.
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).