Last modified: 2010-05-15 15:37:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3960, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1960 - Rewrite of accesskey javascript akeytt
Rewrite of accesskey javascript akeytt
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.5.x
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
http://jadesukka.homelinux.org:8180/m...
: patch, patch-need-review
Depends on:
Blocks: javascript
  Show dependency treegraph
 
Reported: 2005-04-23 19:22 UTC by Niklas Laxström
Modified: 2010-05-15 15:37 UTC (History)
0 users

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


Attachments
A patch for akeytt (2.08 KB, patch)
2005-04-23 19:23 UTC, Niklas Laxström
Details

Description Niklas Laxström 2005-04-23 19:22:59 UTC
I was going to add accesskeys to next and previous links in the history browsing
modes, but run problems with akeytt. Looks like it tries to find a element,
which child is a a-element. That's ok because almost all those links are in
format li > a. If the else-clause was meant to be fallback, which I think it was
meant to be, it didn't work. So i rewrote the function so it tries to find a
a-element directly or in the first child element.

Ask for clarification if you don't understand my poor explanation. Nevertheless
i'll add a patch for it.
Comment 1 Niklas Laxström 2005-04-23 19:23:31 UTC
Created attachment 452 [details]
A patch for akeytt
Comment 2 Brion Vibber 2005-04-24 11:11:21 UTC
It's a little unclear what problem this patch is solving. :)

Can you clarify what breaks with the current code, and how this fixes it?
Comment 3 Niklas Laxström 2005-04-24 11:46:51 UTC
Well...
The original basically changed <xxx id="b"><a> construct to <xxx id="b"><a
title="xy" acceskey="x">.
The problem was that it didn't work if the id was put directly to anchor
element, like <a id="c">. In other words you have to encapsulate the link with
another element with id in it.

My version first checks if the given tag is an anchor element (<a id="c">) and
if it isn't, it falls back to the original behaviour. In other words it tries to
assign accesskey parameter to anchor element, not only to the first child of
element which has the id we searched for. I think this is also how the original
version was meant to behave.

This problem came up as i was adding accesskeys to next/previous diff links
which were not encapsulated by another element.

Original:
<xxx id="b"><a> to <xxx id="b"><a title="xy" acceskey="x">

New:
<xxx id="b"><a> to <xxx id="b"><a title="xy" acceskey="x">
or
<a id="c"> to <a id="c" title="xy" acceskey="x">
Comment 4 Niklas Laxström 2005-08-19 21:18:04 UTC
I've committed this to HEAD, no problems reported so far.

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


Navigation
Links