It's working for me.

I think we can solve this now, after Chuck changed the modifier key to 
Ctrl on Macs?

Right... I'm saying that the javascript should be consistent with how 
accesskeys are handled - right now it's not. And a preference is worse 
because I can use accesskeys on both mac and win; with a preference I 
have to pick one.



To be clear, right now accesskeys don't work at all on the mac - the 
command key isn't available to override in the way that the keyhandler 
is doing it it seems.

Because currently, the key *is* defined by the browser/platform 
combination. Users will complain if the key is no longer the same.

Why haven't we heard those with the current access keys, though?

True, but given the different access key modifiers on different 
platforms and browsers, I can already hear the (valid) complaints 
about the key being different to the user's favorite platform/browser 
combination.

If it's a preference, then I have to pick one key, and if I end up 
using another platform's browser, I'd have to change the preference 
(and then change it back) if I want accesskeys. I don't think this is 
a good idea.

Ah right, this was on the todo list too. I would rather like to make 
this a preference.

I'm guessing this is Alt-key specific right now? It doesn't work for 
me (FF/Mac), but that's probably because Alt/Command is the OS 
shortcut key on Macos. Any objection to having the script platform 
sniff and use Ctrl instead of Alt on Mac?

Some explaining comments:

Any element that has at least 1 event listener added to it via 
Event.observe() has the attribute '_prototypeEventID' set.  This 
attribute links to the location in the Event.cache() which contains 
the observe information.  This code snippet will return the 
Event.cache element if it exists and if it has at least 1 observed 
event (looks like the Event.cache array is not pruned when the last 
observer is removed)

I have implemented a javascript access key handler in CVS HEAD which 
seems to work great so far. It doesn't handle onclick events yet that 
have been attached programatically though.



Here's some code snippet from Michael that should do that trick:



$H(Event.cache[$(element)._prototypeEventID.first()]).findAll(function(h) { 
return h.key && h.value.flatten().size(); });

Brilliant on the Greasemonkey script. Works perfectly. Thanks!

I wrote a Greasemonkey user script to remove duplicate accesskey 
attributes to deal with this issue.  People can use it until IMP is 
fixed.



http://userscripts.org/scripts/show/29539

Yes this is a very large issue that was overlooked, many online forums 
(vBulletin) have an issue with this double access key issue. I need a 
solution ASAP! if anyone can come up with it.

I thought so too, but at least in IMP, since we re-use the same 
template to render the bottom navbars, we still get doubled accesskeys.

This is already the default behavior of the access keys methods.

In Firefox 3, if we output two identical accesskey="..." links on a 
page, then pressing the accesskey will select the first matching link 
instead of following it. This happens on pages where we have top and 
bottom navbars, for instance.



We should figure out a way to either never output a second instance of 
the same accesskey, or have some javascript that post-processes links 
and removes duplicates.