Page MenuHomePhabricator

URL as link-text creates extra, empty, link
Closed, ResolvedPublic

Description

Author: timwi

Description:
BUG MIGRATED FROM SOURCEFORGE
http://sourceforge.net/tracker/index.php?func=detail&aid=974082&group_id=34373&atid=411192
Originally submitted by Rowan Collins (imsop) 2004-06-16 19:47

A link of the form [http://www.example.net
http://www.example.net] produces an additional, empty,
link before the real one - an opening "a" tag with all
the right attributes, which is immediately closed, and
followed by an identical one that contains the actual
link text.

The result is that a default MonoBook setup will show
"[link-icon]http://www.example.net[link-icon]" instead
of the expected "http://www.example.net[link-icon]".
The bug may have been around for some time, since it
exists in standard skin but is invisible in the
rendered page.

Note that this is *not* the same as #583234
(https://sourceforge.net/tracker/index.php?func=detail&aid=583234&group_id=34373&atid=411192)
and all its duplicates, as the URL itself is perfectly
normal.

Finally, note also that this style of URL was actually
encouraged at one stage as the automatic detection of
plain-text links was not guaranteed to work forever. (I
can't find the page I read that in now, I suspect it
has been changed.)

{en|meta}:User:IMSoP

  • Additional comments ------------------------

Date: 2004-06-16 22:20
Sender: SF user imsop

A more revealing test-case just occurred to me, and has some
rather weird results:

[http://www.example.net/foo http://www.example.net/bar]
gives an *empty* link to .../foo and the text (".../bar") is
linked to .../bar

In other words, the intended target is being given a
textless link, and the intended text is then being turned
into a plain link.

[Amusingly, this would foil anyone trying to mislead people
by making a bracketed link to one thing look like a

plain-text link to another.]

Date: 2004-07-09 13:32
Sender: nobody
Logged In: NO

This is apparently related: URL containing "http://", i. e. Web
Archive cache, can't be re-titled:

[http://web.archive.org/web/20010808121638/http://www.wik
ipedia.org/ Early Wiki homepage] makes only a live link to
http://www.wikipedia.org/ surrounded by the rest including
brackets as if it were in .

en:user:Malyctenar


Version: unspecified
Severity: minor

Details

Reference
bz126

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 6:46 PM
bzimport set Reference to bz126.
bzimport added a subscriber: Unknown Object (MLST).

wikibug.5.starfury wrote:

*** Bug 139 has been marked as a duplicate of this bug. ***

wmahan_04 wrote:

Both the the examples

[http://www.example.net http://www.example.net]
[http://www.example.net/foo http://www.example.net/bar]

are fixed in 1.4pre CVS.

apb wrote:

If the link text looks like an URL to an imge, then the image is displayed,
instread of the link text being displayed.

For example <nowiki>[http://www.wiktionary.org/ http://commons.wikimedia.org/
upload/4/4a/Wiktionary-logo-en-35px.png]</nowiki> produces HTML code like
<nowiki><a href="http://www.wiktionary.org"><img src="http://commons..."></
nowiki>, whereas I would have expected it to produde HTML code like <nowiki><a
href="http://www.wiktionary.org">http://commons...</a></nowiki>.

I think this is a bug (something that is documented as text ends up being used
as an URL to an image), but it is used as if it were a feature at [[meta:
Template:WikipediaSister]].

rowan.collins wrote:

(In reply to comment #3)

If the link text looks like an URL to an imge, then the image is displayed,
instread of the link text being displayed.
[...]
I think this is a bug (something that is documented as text ends up being used
as an URL to an image), but it is used as if it were a feature at [[meta:
Template:WikipediaSister]].

Well, I'd say that's almost a "correct" behaviour - with the configuration
option "$wgAllowExternalImages=true;" (as is set on meta, but not on other
Wikimedia sites, as it is rather a vandalism-risk) a bare URL pointing to an
image will be rendered as an image, not as a link. Given that other formatting
is allowed in the "description" portion of the "[URL description]" (e.g.
"[http://example.com foo ''bar'' baz]" has an italicised "bar" in the
description, not the text "''bar''"), it stands to reason that a description
which includes, or consists of, an image URL will contain an inline image when
rendered, not be forced into plain text. [In which case there's a minor bug in
that this *doesn't* happen if there's text present as well as the image URL.
*shrug*]

Meanwhile, the bug this report is actually about is now very much fixed, and
since all Wikimedia sites are now running the 1.4 betas, I'm going to "resolve" it.