loading...

How to handle outbound links in desktop PWA?

ben profile image Ben Halpern ・1 min read

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?

Posted on by:

ben profile

Ben Halpern

@ben

A Canadian software developer who thinks he’s funny. He/Him.

Discussion

markdown guide
 

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.

 

Yup, in fact the first thing I try to change in native mobile apps, if possible, is the behavior that opens links in "in-app" browsers.

 

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 πŸ‘

 

I'd hate to browse within a desktop app that's not my browser, notably because I use an adblocker.

I'd expect the PWA to act like every other software, which means using the default tool to open links (letting the OS manage, basically).

Also, about target=_blank, a good read around security, as it could create some huge flaws.

 

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.

 

Sooo, I haven't checked on this for a while.

Did you test for such a vulnerability since then?

 

Does this maybe help?
developer.mozilla.org/en-US/docs/W...

Defines the navigation scope of this website's context. This restricts what web pages can be viewed while the manifest is applied. If the user navigates outside the scope, it returns to a normal web page inside a browser tab/window.

 

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"

"Caution: If the user clicks a link in your app that navigates outside of the scope, the link will open and render within the existing the PWA window. If you want the link to open in a browser tab, you must add target="_blank" to the <a> tag. On Android, links with target='_blank' will open in a Chrome Custom Tab."

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=self to all internal/dev.to links.

 

As others have said, I like the "pseudo-browser". It is a familiar pattern for Android/Chrome users.
Dev PWA

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=_blank to 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=_blank forces 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.

  • In the PWA context menu, I can choose to open links in an external browser, private window, etc.
  • In the browser's context menu, I can choose to open DEV.to links in a PWA window.

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.

 

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).

 

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!

 

As a user I prefer the "in-app pseudobrower" solution.