Last modified: 2008-08-13 15:17:54 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"> <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.
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.
Keywords: patch, testme, need-review
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.
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.
