Last modified: 2010-05-15 14:36:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 126 - URL as link-text creates extra, empty, link
URL as link-text creates extra, empty, link
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
: 139 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-16 06:04 UTC by Timwi
Modified: 2010-05-15 14:36 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Timwi 2004-08-16 06:04:25 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
Comment 1 Addicted 2004-08-16 13:35:45 UTC
*** Bug 139 has been marked as a duplicate of this bug. ***
Comment 2 Wil Mahan 2004-09-30 21:09:18 UTC
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.
Comment 3 Alan Barrett 2005-02-09 21:00:54 UTC
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]].
Comment 4 Rowan Collins [IMSoP] 2005-02-09 21:53:26 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links