Inconsistent behaviour for links

[Ravenbird]

Expected behavior

I just had it with Michael Vogel that my Friendica internal hyperlinks are partly opened in new windows and external hyperlinks in the same window. And that is not so consistent. Wouldn't it make more sense if internal links (in Friendica everything that runs on your own instance) were opened in the same window and everything that runs on another instance or on another web page was opened in a new window?

Steps to reproduce the problem

I don't know now how to describe how to reproduce it here. My English is just not good enough for that. I already had it with Michael about this: https://talk.anarchismus.xyz/display/f9b88ec4-125e-4f83-b53e-ca6318777991

Friendica version you encountered the problem

The related Friendica version is 2019.12, which is the current stable version.

[MrPetovan]

Can you identify which links open in new pages? They probably shouldn't. The recommended policy is to let users decide whether they want to open any link in the same page or in a different page and not force either of these behaviors.

Therefore, the correct consistency would be to open all links in the same page by default.

[annando]

@MrPetovan In fact we do have many links that are set to target="_blank".

[MrPetovan]

Sounds like I'm going to perform a little spring cleaning.

[annando]

Before changing that. we should discuss it. There are different opinions about this behaviour.

Edit: I would rather vote for a possibility to switch the target via some configuration between "always open in the same window" and "open external links in a new window". This could then be used to possibly have different behaviours for mobile and desktop or for internal and external profile links.

[MrPetovan]

So we’re talking about 4 new settings? 😱

My solution is simpler and empower users the most without adding settings complexity.

[annando]

It is a "user acceptance" problem with the links. People expect that external links open in external pages - and especially on mobile systems a right click to open in a new page is problematic. I'm speaking of a single new setting with these values:

• Open external links in new tab
• Open external links in new tab only on mobile
• Always open all links in the same tab

[Ravenbird]

Personally I think very much of the approach of Michael (annando). I also see two fundamentally different platforms, the desktop browser and the mobile browser. With the desktop browser you can easily determine with the middle and right mouse button whether a link should be opened in the same window/tab or in a new window/tab. This is unfortunately not the case with the mobile browser, where it is very complicated. Just to hit the link when you have thick fingers is often a struggle.

I myself would prefer that internal links are opened in the same window/tab and external links in a new window/tab. This can clearly be done by default, but on the other hand it's good to give the user the choice.

[MrPetovan]

Here's the problem with external links in Friendica. We have some links that are initially internal (/redir), then redirect to another domain, and that are still expected to open in the same page because of remote authentication. This happens with remote Friendica profile link and "Link to Source" post links. What should be their behavior in any of the three setting values proposed?

In the same fashion, the "Link to Source" links on the same node's posts looks like an external link, and yet it should open in the same tab because it's on the same domain.

As for mobile/desktop, iOS already opens external links in a separate app from a Progressive Web App.

Even beyond that, we don't have a centralized way of defining a link and whether it should open in a new tab or not depending on a setting. This would require a massive rewrite of many templates to provide a feature that should be up to clients.

It isn't just me, please check out this article about the good reasons to use target="_blank", we don't meet any of the three presented. I also learned target="_blank" has a security vulnerability by default and requires another attribute to be set to address it.

To summarize my point:

• target="_blank" is insecure by default.
• target="_blank" forces a specific behavior on users which isn't the default one.
• Even if many websites use it, they have their own definition of internal/external links that isn't a standard in any way.
• We do not even have a clear conception of internal/external links in Friendica.
• We have no centralized way of implementing a link behavior setting.
• This setting is up to browsers anyway which actually are implementing it.

I'm strongly against it, especially while we are trying to reduce Friendica's settings footprint.

[annando]

Even with "redir" we can easily determine if the link goes to some external or internal resource. I also don't think that it would be that much work, compared with other things that we do in the code.

Concerning the removed settings: Settings have to be precise and without side effects that users don't expect (like with "hidewall" and the connectors"). I think that this setting wouldn't be imprecise. However, I would prefer just having this behaviour directly in the system without any setting.

From my point of view we have to see a Friendica site not as a regular webpage, but like an application. When using Friendica via an application, you also wouldn't want to have your app closed (with the need to restart it) when you click on a link to some external resource. We mostly do have resident users on our systems, guests are the exception. That's the difference to - for example - some corporate website or some news outlet where you stumbled upon because you found the link via some search engine.

[Ravenbird]

Just an idea/suggestion. Some websites show a short preview/info page when they call an external page and as far as I have seen this should work with a page opened in a new tab/window. You could even work with two preview pages. One for external pages within the sprung network and one for external pages without reference to the sprung network. Just as a thought.

[MrPetovan]

The external link preview also is a client-side feature. I deactivated it on my mobile browser because I'm on a metered plan again for roaming Internet. I wouldn't want Friendica to offer it by default either, even behind another setting.

From my point of view we have to see a Friendica site not as a regular webpage, but like an application.

I concede that we are in a weird state where Friendica isn't a traditional website anymore, but it isn't a fully-formed app yet either.

Anyway, I did a search on target="_blank", I found:

• src/: 21 matches in 5 files.
• view/: 18 matches in 11 files.
• addon/: 4 matches in 3 PHP files.

None of the matches are using rel="noopener" which means we are vulnerable to opener tampering. This would be easily solved with a centralized link function though, so I'm not too concerned about it but I think we should fix it as soon as possible, and removing the currently inconsistent target="_blank" is the easiest way to kill two birds with a single stone. Then when you have the time you can add consistent external link behavior back if you want.

Here's the corresponding PR: #8334

[annando]

Can we defer this to the next release?

[MrPetovan]

Yes. The security part of it has been taken care of, so now it's just the usability part left.

[MrPetovan]

Removing from release as the bug/security part has been taken care of and I have no personal interest in pursuing this issue anymore.