Last modified: 2010-05-15 15:37:55 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 1960 - Rewrite of accesskey javascript akeytt
Rewrite of accesskey javascript akeytt
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: 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: ---

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

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
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.

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

<xxx id="b"><a> to <xxx id="b"><a title="xy" acceskey="x">
<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.