6.0.0-git
2019-03-18

[#6803] Accesskeys in Firefox 3
Summary Accesskeys in Firefox 3
Queue Horde Base
Queue Version HEAD
Type Bug
State Resolved
Priority 1. Low
Owners Horde Developers (at)
Requester chuck (at) horde (dot) org
Created 2008-05-31 (3943 days ago)
Due
Updated 2008-09-22 (3829 days ago)
Assigned 2008-09-22 (3829 days ago)
Resolved 2008-09-22 (3829 days ago)
Milestone
Patch No

History
2008-09-22 14:22:45 Chuck Hagenbuch Comment #17
State ⇒ Resolved
Reply to this comment
It's working for me.
2008-09-22 12:57:35 Jan Schneider State ⇒ Feedback
 
2008-09-22 12:57:20 Jan Schneider Comment #16 Reply to this comment
I think we can solve this now, after Chuck changed the modifier key to 
Ctrl on Macs?
2008-08-22 16:14:52 Chuck Hagenbuch Comment #15 Reply to this comment
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.
2008-08-22 16:04:38 Jan Schneider Comment #14 Reply to this comment
Because currently, the key *is* defined by the browser/platform 
combination. Users will complain if the key is no longer the same.
2008-08-22 15:58:37 Chuck Hagenbuch Comment #13 Reply to this comment
Why haven't we heard those with the current access keys, though?
2008-08-22 15:56:36 Jan Schneider Comment #12 Reply to this comment
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.
2008-08-22 15:51:18 Chuck Hagenbuch Comment #11 Reply to this comment
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.
2008-08-22 08:29:37 Jan Schneider Comment #10 Reply to this comment
Ah right, this was on the todo list too. I would rather like to make 
this a preference.
2008-08-22 02:51:37 Chuck Hagenbuch Comment #9 Reply to this comment
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?
2008-08-20 20:52:35 Jan Schneider Comment #8 Reply to this comment
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)
2008-08-20 20:51:35 Jan Schneider Comment #7
Taken from Chuck Hagenbuch
Reply to this comment
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(); });
2008-07-03 20:59:43 horde (dot) org (at) stuart5 (dot) com Comment #6 Reply to this comment
Brilliant on the Greasemonkey script. Works perfectly. Thanks!
2008-07-03 19:21:57 westphal (at) umich (dot) edu Comment #5 Reply to this comment
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
2008-06-17 21:18:23 rhett (at) rhettbuck (dot) net Comment #4 Reply to this comment
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.
2008-06-01 13:30:10 Chuck Hagenbuch Comment #3 Reply to this comment
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.
2008-06-01 09:51:03 Jan Schneider Comment #2 Reply to this comment
This is already the default behavior of the access keys methods.
2008-05-31 15:53:28 Chuck Hagenbuch Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 1. Low
Summary ⇒ Accesskeys in Firefox 3
Queue ⇒ Horde Base
Assigned to Chuck Hagenbuch
Assigned to Horde DevelopersHorde Developers
Milestone ⇒
Patch ⇒ No
Reply to this comment
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.

Saved Queries