DEV Community

loading...

How to handle outbound links in desktop PWA?

Ben Halpern on May 21, 2019

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 + promp...
Collapse
jsrn profile image
James

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.

Collapse
yaser profile image
Yaser Al-Najjar

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

Collapse
pedrootero profile image
Pedro Otero Prada

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.

Collapse
islam profile image
Islam Sayed

I agree with that. I even when it opens in app I choose open in chrome option.

Collapse
n_develop profile image
Lars Richter

I agree. I like it better, when external links open in a browser.

Collapse
teotcd profile image
JedDevs • Edited

Agreed, but some sort of pop up to make sure you want to leave the app would be ๐Ÿ‘

Collapse
ganapativs profile image
Ganapati V S ๐Ÿ˜Ž • Edited

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.

Collapse
ben profile image
Ben Halpern Author

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.

Collapse
moopet profile image
Ben Sinclair

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.

Collapse
niorad profile image
Antonio Radovcic • Edited

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.

Collapse
ben profile image
Ben Halpern Author

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.

Collapse
niorad profile image
Antonio Radovcic

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.

Thread Thread
terabytetiger profile image
Tyler V. (he/him) • Edited

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.

Thread Thread
ben profile image
Ben Halpern Author

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

Thread Thread
ben profile image
Ben Halpern Author

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

Collapse
ryansmith profile image
Ryan Smith

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.

Collapse
sn0n profile image
Rob Foraker

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

Collapse
zcdunn profile image
Zack Dunn • Edited

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.

Thread Thread
ryansmith profile image
Ryan Smith • Edited

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. ๐Ÿ™

Collapse
sn0n profile image
Rob Foraker

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.

Collapse
moopet profile image
Ben Sinclair

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!

Collapse
abhinav1217 profile image
Abhinav Kulshreshtha

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.

Collapse
vinibrsl profile image
Vini Brasil • Edited

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

Collapse
lionelrowe profile image
lionel-rowe

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.

Collapse
kasuken profile image
Emanuele Bartolesi

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

Collapse
bsde1234 profile image
bsde1234

I am trying to open my external link inreal browser instead in-app browser. How to do it?