Created attachment 5059
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.

Attached:

Keywords: patch, testme, need-review

ayg wrote:

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.

ayg wrote:

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.