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
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T21270 Relative URIs in interwiki links table break interwiki transclusion | |||
| Resolved | None | T20664 Relative URIs in interwiki links table causes failed redirects | |||
| Resolved | None | T22342 Support for protocol-relative URLs | |||
| Invalid | None | T32682 Link icon inconsistencies when using protocol relative URLs |
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.
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.
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.
(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).
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.
We no longer use the padlock icon for https links (since T63178), hence this is no longer reproducible. Closing.