Community
Participate
Working Groups
To reproduce 1. create a composite widget (for example), add a key listener 2. set active keys like "CTRL+A","CTRL+B", ... 3. open application, focus widget and type these combos -> listener is not notified for all combos. For example, in Webkit CTRL+B and CTRL+D work, while CTRL+C and CTRL+D don't. Adding the same keys to CANCEL_KEYS seems to make not work at all anymore. Also, in some cases the wrong char/key code seem to be sent. This is different from Bug 367875 (ActiveKeys with CTRL+[char] don't work on Text widget) in that it only concerns IE and webkit browser, and that its true for all widgets.
Since the code in question will be heavily changed with fixing Bug 367871, we should wait to see if that resolves this issue.
ALT+[char], namely ALT+1, also does not work on Chrome.
On Chrome there are also other problems. If F5 is added to the ACTIVE_KEY list on the Display it breaks: Pressing F5 on a rap application in Chrome gets the messagebox "The server seems to be temporarily unavailable. Would you like to retry?" - Ctrl-R reloads the application as expected.
F5 reloads the document while also triggering an ajax-request, which is problematic. (An easy workaround could be to add F5 to the cancel keys.) Question is what the expected behavior would be: Reloading the document (i would think so, if its not canceled), or sending the request and not reloading, or sending the request and reload after that.
As far as i can tell the problem is that these are shortcuts that trigger native browser behavior and therefore don't fire no keypress event. The solution could be to send keyevents on keydown, ignore the first keypress, then send on all other keypress. This might not work in all cases (though most), but it might also solve Bug 367875 and Bug 366788. Problem is that we don't know the char code in these cases, not sure yet how to handle that.
(In reply to comment #4) > F5 reloads the document while also triggering an ajax-request, which is > problematic. (An easy workaround could be to add F5 to the cancel keys.) > Question is what the expected behavior would be: Reloading the document (i > would think so, if its not canceled), or sending the request and not reloading, > or sending the request and reload after that. Sorry I didn't mention this: It breaks ether way with or without F5 in the CANCEL_KEYS.
Fixed in CVS HEAD. This required a larger refactoring of KeyEventSupport.js, and EventHandler.js. Basically, missing keypress events are re-created, keydown events are treated with priority obver keypress events, and the process of canceling domEvents has been moved to a lower level to capture events normally ignored. F5 now works if its in CANCEL_KEYS, but otherwise it still shows the error message. I will open another bug for that.
Thank you, I'll try it asap.
