Last modified: 2011-05-02 21:08:25 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 28182 - Title attribute is missing for some internal links
Title attribute is missing for some internal links
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Normal minor (vote)
: ---
Assigned To: Mark A. Hershberger
Depends on:
Blocks: 542
  Show dependency treegraph
Reported: 2011-03-22 13:11 UTC by Huji
Modified: 2011-05-02 21:08 UTC (History)
3 users (show)

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


Description Huji 2011-03-22 13:11:43 UTC
In this example page:

Both redlinks have a title attribute, as does the first blue link ("pages"), but the last link ("Wikipedia") doesn't have a title. On larger pages in other sister projects, it seems like some of the blue links (roughly less than 50% of them) are randomly missing a title attribute.

User:Companionship on Persian Wikipedia should be credited for notifying me about this bug.
Comment 1 AlexSm 2011-03-22 16:00:31 UTC
This was intentional, to avoid titles that duplicate the link text, see Bug 542.
Comment 2 Platonides 2011-03-22 16:04:49 UTC
Blue links only get the page in title if it's different than the text, per Bug 542. See r76127 (I thought that wasn't still live on wikipedia?).
Although given the annoyance to people reported here (waiting for a title that never appears) and the problems to get it right, I'd revert and close 542 as wontfix.
Comment 3 Mark A. Hershberger 2011-03-23 00:44:09 UTC
There do seem to be a fair number of people attached to that title attribute.  That's a lesson for what happens when you change existing behavior in a widely used application.
Comment 4 Huji 2011-03-23 01:11:20 UTC
It's not only attachment. Apparently, some users benefited from the title attribute in their bot codes, and now they have to resolve all redirects in a separate step.
Comment 5 db [inactive,noenotif] 2011-03-24 18:50:20 UTC
(In reply to comment #4)
> It's not only attachment. Apparently, some users benefited from the title
> attribute in their bot codes, and now they have to resolve all redirects in a
> separate step.

Please use the api.php for bots ...

Some Gadgets or user js were broken due to this change.
Comment 6 Platonides 2011-03-25 16:16:13 UTC
It was javascript. And it makes sense to extract it from the a tag rather than performing a XMLHttpRequest (in some cases there's no other option). Unconditionally extracting it from the title attribute was much easier than the parsing they need now.

The main problem I see is that now you don't know if a link will have a title or not, which reduces its usefulness (humans are bad at timeouts). 
Plus I don't see what are the benefits mentioned in bug 542 ("authors could rely more on this feature to convey useful information"), Given that it is then gzipped, I don't consider the space gainings to be definitive, on either way.
Comment 7 Mark A. Hershberger 2011-04-22 17:38:10 UTC
This (reverting bug #542's fix) is an issue that should get more input before a decision is made either way.
Comment 8 Mark A. Hershberger 2011-04-26 03:24:45 UTC
After discussion, I'll revert the fix for bug #542.
Comment 9 Mark A. Hershberger 2011-04-27 21:49:45 UTC

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