Last modified: 2010-05-15 14:36:14 UTC
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
*** Bug 139 has been marked as a duplicate of this bug. ***
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.
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]].
(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.
