6.0.0-git
2019-03-24

[#7866] Update accesskeys in DIMP
Summary Update accesskeys in DIMP
Queue DIMP
Queue Version HEAD
Type Bug
State Resolved
Priority 2. Medium
Owners slusarz (at) horde (dot) org
Requester chuck (at) horde (dot) org
Created 2009-01-17 (3718 days ago)
Due
Updated 2010-01-12 (3358 days ago)
Assigned 2009-03-01 (3675 days ago)
Resolved 2009-03-07 (3669 days ago)
Milestone
Patch No

History
2009-03-07 10:41:54 Jan Schneider Comment #30
State ⇒ Resolved
Reply to this comment
The DIMP-specific issues are solved, I opened a new bug for issues 
with the general access key code: bug #8057.
2009-03-01 13:38:07 Jan Schneider Comment #29
Taken from Horde DevelopersHorde Developers
State ⇒ Assigned
Reply to this comment
I guess the submenu access keys don't work because they are not visible.
2009-02-24 00:28:06 Jan Schneider Comment #27 Reply to this comment
In IMP:



Access keys on mailbox submenus don't work anymore, i.e. for replying to mail.



When hitting the access key to delete messages in the mailbox view, I get:



Fehler: elt.click is not a function

Quelldatei: http://neo.wg.de/horde/js/src/accesskeys.js

Zeile: 33


2009-02-23 07:46:30 Michael Slusarz Comment #25 Reply to this comment
That's because the accesskey was pointing to the wrong element.  Fixed.
The accesskey is supposed to just activate the select, so that you
can start typing a folder name. Now it just submits the form, with no
chance to pick the folder to switch to.
Not sure what I was thinking - this has been fixed.
2009-02-18 16:17:00 Chuck Hagenbuch Comment #24 Reply to this comment
That's because the accesskey was pointing to the wrong element.  Fixed.
The accesskey is supposed to just activate the select, so that you can 
start typing a folder name. Now it just submits the form, with no 
chance to pick the folder to switch to.
2009-02-18 06:02:54 Michael Slusarz Comment #23 Reply to this comment
The access key for the folder selection menu in IMP (upper right, for
switching the view to a different folder) no longer works.
That's because the accesskey was pointing to the wrong element.  Fixed.
I have no problem with getting rid of duplicate access keys in
generated HTML instead of trying to deal with this in js, btw. The
only places we even have them are where we re-output a pre-assigned
template.
I don't think this is an issue anymore - it looks like the javascript 
in the accesskeys.js correctly handles this problem.
2009-02-18 05:50:22 Michael Slusarz Comment #22 Reply to this comment
Have those changes been merged to FW_3 already? I still see issues there.
No.  I was not going to backport until all issues are resolved.
2009-02-17 15:18:33 Chuck Hagenbuch Comment #21 Reply to this comment
The access key for the folder selection menu in IMP (upper right, for 
switching the view to a different folder) no longer works.



I have no problem with getting rid of duplicate access keys in 
generated HTML instead of trying to deal with this in js, btw. The 
only places we even have them are where we re-output a pre-assigned 
template.
2009-02-17 11:09:15 Jan Schneider Comment #20 Reply to this comment
Have those changes been merged to FW_3 already? I still see issues there.
2009-02-17 07:53:30 Michael Slusarz Comment #19 Reply to this comment
Simply put, accesskeys are a PITA.  I think I have fixed the compose
issue, but I wouldn't be surprised if I rebroke something else.
Outside of manually eliminating duplicate accesskeys, I'm not sure
there is much more we can do.
Ping.  Is this still broken for anyone?
2009-02-10 03:28:51 Michael Slusarz Comment #18
State ⇒ Feedback
Reply to this comment
Simply put, accesskeys are a PITA.  I think I have fixed the compose 
issue, but I wouldn't be surprised if I rebroke something else.   
Outside of manually eliminating duplicate accesskeys, I'm not sure 
there is much more we can do.
2009-02-07 17:50:45 Chuck Hagenbuch Comment #16
State ⇒ Assigned
Reply to this comment
I still have the compose screen problem.
2009-02-06 18:21:36 Michael Slusarz Comment #15
State ⇒ Feedback
Reply to this comment
Fixed those 2 issues.
2009-01-28 00:51:06 Chuck Hagenbuch State ⇒ Assigned
 
2009-01-28 00:50:58 Chuck Hagenbuch Comment #13 Reply to this comment
The basics work in DIMP the last time I checked. The issues I know about are:



- accesskey for back to mailbox ("k" in english) in the message view 
doesn't work (just highlights one of the links)

- accesskey for sending a message ("s" in english) on the compose 
screen submits the form twice. the message is sent, but the window 
stays open with a "you have already submitted this form" error



This is FF3/Mac.
2009-01-27 19:22:52 Michael Slusarz Comment #12 Reply to this comment
2009-01-20 20:55:16 Chuck Hagenbuch Comment #10
Taken from Chuck Hagenbuch
Reply to this comment
Getting better - delete works from the message view now. However Back 
to Inbox (k) doesn't work (just selects one of the links, have to hit 
return to activate it), and the View Message accesskey (m) opens two 
windows instead of one.
2009-01-20 18:27:19 Michael Slusarz Comment #9 Reply to this comment
OK - managed to get the FF3 behavior on the message page.  This was 
the topic of Ticket #6803.  IMHO, the proper solution is to remove 
duplicate accesskeys rather than trying to work around the various tag 
types - especially since the standard does seem to highy discourage 
duplicate accesskeys (which makes sense).
2009-01-20 17:55:45 Michael Slusarz Comment #7 Reply to this comment
I haven't had a chance to try this in DIMP yet, but it sounds great.
However, it means that accesskeys.js no longer works for its original
purpose - fixing accesskeys in FF3. With any duplicated links (delete
message, which appears at the top and bottom of the message view,
etc.), the access key is just highlighted now, not activated.
How so - meaning, why wouldn't the current code work?  This works fine 
for me in FF3/Win - I just tried it on the mailbox page w/30 messages 
in IMP and Delete works fine even though the access key is deleted.


2009-01-20 16:15:24 Chuck Hagenbuch Comment #6 Reply to this comment
I haven't had a chance to try this in DIMP yet, but it sounds great. 
However, it means that accesskeys.js no longer works for its original 
purpose - fixing accesskeys in FF3. With any duplicated links (delete 
message, which appears at the top and bottom of the message view, 
etc.), the access key is just highlighted now, not activated.



It does fix a problem that went along with that, where using the new 
message access key caused that link to activate twice.
2009-01-20 07:01:22 Michael Slusarz Comment #4
State ⇒ Feedback
Reply to this comment
Michael, if you've already got something in mind for this, or another
approach makes more sense to you, please let me know.
Actually yes - the correct way to do this is via triggering a DOM 
event -- this is a DOM level 2 action, so that means that most 
browsers should support it.  (Of course) It seems that IE handles 
things a bit differently, see:

http://www.howtocreate.co.uk/tutorials/javascript/domevents

so I think we need to use createEventObject() instead for IE (this is 
what prototypejs does, for instance).
2009-01-17 17:19:25 Chuck Hagenbuch Comment #2
Assigned to Michael Slusarz
Reply to this comment
Michael, if you've already got something in mind for this, or another 
approach makes more sense to you, please let me know.
2009-01-17 17:18:34 Chuck Hagenbuch Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 2. Medium
Summary ⇒ Update accesskeys in DIMP
Queue ⇒ DIMP
Assigned to Chuck Hagenbuch
Assigned to Horde DevelopersHorde Developers
Milestone ⇒
Patch ⇒ No
Reply to this comment
With the new event code in DIMP, accesskeys don't work. I think having 
a hash with the various events in it (currently defined in the 
clickhandler), and giving DIMP an accesskey implementation that would 
call into the same hash would work.

Saved Queries