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?
Technically you could do it the other way only in case of PWA.
Set target blank as default for anchor tag.
Add target=self to all internal/dev.to links.
Does this maybe help?
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"
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.
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=_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.
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!
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.
As a user I prefer the "in-app pseudobrower" solution.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.