Link icon inconsistencies when using protocol relative URLs
OpenPublic

Description

Author: theevilipaddress

Description:
Please note that the linking icon of links to exactly the same location might look completely different, depending on if they use protocol relative URLs or not. I don't know how (or if) to fix that, but wanted to let you know.


Version: unspecified
Severity: normal
URL: https://test.wikipedia.org/w/index.php?title=Sandbox&oldid=116539
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61178

bzimport added a project: MediaWiki-Interface.Via ConduitNov 21 2014, 11:52 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz30682.
bzimport created this task.Via LegacySep 1 2011, 2:20 PM
Catrope added a comment.Via ConduitSep 1 2011, 2:23 PM

I don't understand what you mean. Could you provide an example or a screenshot?

bzimport added a comment.Via ConduitSep 1 2011, 2:24 PM

theevilipaddress wrote:

Added a URL.

Catrope added a comment.Via ConduitSep 5 2011, 6:05 PM

Looking at the URL I get it now.

[http://foo.com Foo] and [//foo.com Foo] both get the normal external link icon (blue square with an arrow at a 45-degree angle), while [https://foo.com Foo] gets the secure link icon (lock). When viewed over HTTPS, the protocol-relative link and the HTTPS link will have the same target but a different icon.

I'm not sure this is at all fixable without causing cache pollution.

Seb35 added a comment.Via ConduitSep 15 2011, 9:07 PM

I’m not sure if it should be fixed, it depends of the interpretation of each symbol.

Previously (in all-http mode) the lock emphasized the link is in https (exception to the http standard protocol) and the blue arrow simply indicated a link.

Now in https, given external links are also used for internal links (link to action=edit for instance), fixing this bug would mean many locks would appear in https mode and I’m not sure it is desirable for internal external links (at least). It could also be argued that the blue arrow is a "normal" link and the lock has the special meaning of emphasizing an https link.

Else to solve this issue, a solution could be to have a special icon for protocol-relative links which would be different in http or https mode (special configuration of the server/Apache). It’s a bit complicated and not easily deployable/packageable, perhaps not possible. Or it could be indicated in mediawiki.org as a customization for sysadmins.

TheDJ added a comment.Via ConduitOct 5 2011, 3:43 PM

inconsistent, but only because our usage of the links is not yet very much consistent yet.

It might help though, to deploy: r98690 to make it a BIT more consistent.

Catrope added a comment.Via ConduitDec 20 2011, 3:41 PM
  • Bug 33269 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Via ConduitDec 29 2011, 11:15 AM

(In reply to comment #3)

Looking at the URL I get it now.

[http://foo.com Foo] and [//foo.com Foo] both get the normal external link icon
(blue square with an arrow at a 45-degree angle), while [https://foo.com Foo]
gets the secure link icon (lock). When viewed over HTTPS, the protocol-relative
link and the HTTPS link will have the same target but a different icon.

I'm not sure this is at all fixable without causing cache pollution.

We could serve a different icon per protocol on bits.wikimedia.org/..../icon_current_protocol.png :D

Just kidding, alternatively we could add a class to <html> in mediawiki.page.startup and use that in CSS for .mw-https > [href ^="//"]; Although that is cache friendly and not WMF specific and also works for dynamically inserted links, it does mess with cascading system a little bit (in that overriding this with a different icon from somewhere else becomes less trivial and might break existing rules).

Hazard-SJ added a comment.Via ConduitNov 24 2012, 9:00 PM

Hello, has any progress been made, I was about to report this and found that it was reported over a year ago, and there have been no comments for almost 11 months now.

Krinkle added a comment.Via ConduitNov 25 2012, 6:15 PM

I've given a possible implementation. Feel free to implement it, someone.

Add Comment