|Summary:||inconsistent symbol for NumLock/Clear on macOS|
|Product:||ThinLinc||Reporter:||Pierre Ossman <ossman>|
|Component:||Web Access||Assignee:||Pierre Ossman <ossman>|
|Priority:||P2||Keywords:||aleta_tester, relnotes, upstream|
|Bug Depends on:||6152|
Description Pierre Ossman 2019-10-31 12:27:14 CET
Web Access when used on macOS (and iOS?) gives different symbols for the NumLock/Clear key depending on the browser. For reference the native viewer always sends NumLock. Unfortunately I could not find a rationale for this. We should decided on something here and be consistent about it. Before bug 6152 we didn't send anything for this key.
Comment 1 Pierre Ossman 2019-11-01 12:42:42 CET
Chrome and Firefox both result in Clear being sent. But Safari gives KP_Begin (see bug 7419 for that whole mess). The difference is caused by Chrome and Firefox setting location to STANDARD, but Safari sets NUMPAD.
Comment 2 Pierre Ossman 2019-11-01 13:01:42 CET
Reported Safari's behaviour upstream: https://bugs.webkit.org/show_bug.cgi?id=203731
Comment 3 Pierre Ossman 2019-11-01 13:02:42 CET
It's not obvious what works best here. Let's go with what the native client does as it has been doing this for quite some time. NumLock didn't work at all in Web Access before bug 6152.
Comment 4 Pierre Ossman 2019-11-01 13:18:08 CET
Comment 7 Samuel Mannehed 2019-11-05 10:17:57 CET
Fixed now. Tester should verify that the keypad Clear sends NumLock in Web Access.
Comment 8 Samuel Mannehed 2019-11-05 10:36:57 CET
(In reply to comment #7) > Tester should verify that the keypad Clear sends NumLock in Web Access. Tester should also verify that NumLock in general still works, and that KP_5 without NumLock sends a working Clear.
Comment 9 Alex Tanskanen 2019-11-05 13:36:11 CET
Tested this for macOS on: * Firefox 70 * Chrome 77 * Safari 13 It works fine on these browsers.