Last modified: 2008-08-13 15:17:54 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 T16757, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14757 - Double accesskeys cause problems
Double accesskeys cause problems
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
: accessibility, patch, patch-need-review, testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-08 13:09 UTC by Dan Wolff
Modified: 2008-08-13 15:17 UTC (History)
2 users (show)

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


Attachments
Test patch (4.91 KB, patch)
2008-07-09 04:42 UTC, Brion Vibber
Details

Description Dan Wolff 2008-07-08 13:09:32 UTC
If you're logged in to a MediaWiki wiki and check the source code of any edit page (at least in Monobook) you'll see that for the "minor edit checkbox" there's an accesskey specified both for the checkbox itself and its label:

<input ... accesskey="i" id="wpMinoredit" type="checkbox">&nbsp;<label for="wpMinoredit" ... accesskey="i">...</label>

The same goes for id="wpWatchthis", and possibly others on other pages. I'm not sure.

This doesn't cause a problem in most browsers, but Firefox 3 doesn't understand what to do and doesn't respond to it at all – i.e. the accesskey doesn't work in Firefox 3. It'll only understand if the accesskey is on *either* the input or the label. Also, it doesn't really make sense to have it twice. Since at least Opera doesn't support accesskeys on labels I'd recommend we just have it on the checkbox.

I know it would be good if this was fixed in Firefox 3 too, so I have filed a bug there too.
Comment 1 Brion Vibber 2008-07-09 04:42:52 UTC
Created attachment 5059 [details]
Test patch

Did some tweaking on this one for fun...

Attached patch redoes how some of the tooltip stuff gets loaded and tries passing on the tooltip 'title' without the 'accesskey' onto the label.

The problem I see is that the JavaScript fixups for which control key needs to be listed in the tooltip only get applied to elements which *have* the accesskey, not to their labels. Thus you get an incorrect tooltip.

The JS code could be fixed up to look for labels as well, or we could do something else.
Comment 2 Siebrand Mazeland 2008-08-13 11:38:35 UTC
Keywords: patch, testme, need-review
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-13 14:37:09 UTC
I didn't know about this bug.  (Or I did but forgot about it.)  I think I fixed this in r37834, r37876, which have been live for about a month now.  It was a three-line fix to just get rid of the accesskeys for the labels.

Unfortunately you're right about the issue with the title attribute.  I hadn't thought of that.  I'll look into that now; it shouldn't be hard.  The only special case we want here is that labels should get their title adjusted for the accesskey of their accompanying input.

Note that Firefox 3 doesn't *ignore* the accesskey.  If there are multiple matches, triggering the accesskey toggles focus between them.  So Alt-Shift-I focused the "minor edit" checkbox (since it's first in the source), and hitting Enter or Space or whatever would then toggle it.  If you hit Alt-Shift-I again, it would shift focus to the label.  This is actually more intelligent behavior than "activate the first match", which could end up activating something different from what the user expected.  It might have been smart of them to try to detect when all elements with an accesskey have the same behavior when activated, if that makes sense, but this isn't really a bug so much as an annoying consequence of a fairly reasonable behavior change.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-13 15:17:54 UTC
The issue with the missing tooltip hints should be fixed in r39287, backported to 1.13 in r39288.  Not as prettily as Brion's patch, though, I'm afraid.

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


Navigation
Links