Bug 7423

Summary: inconsistent symbol for NumLock/Clear on macOS
Product: ThinLinc Reporter: Pierre Ossman <ossman>
Component: Web AccessAssignee: Pierre Ossman <ossman>
Status: CLOSED FIXED    
Severity: Normal CC: aleta, samuel
Priority: P2 Keywords: aleta_tester, relnotes, upstream
Version: trunk   
Target Milestone: 4.11.0   
Hardware: PC   
OS: Unknown   
Acceptance Criteria:
Bug Depends on: 6152    
Bug Blocks: 3523    

Description Pierre Ossman cendio 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 cendio 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 cendio 2019-11-01 13:01:42 CET
Reported Safari's behaviour upstream:

Comment 3 Pierre Ossman cendio 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 7 Samuel Mannehed cendio 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 cendio 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 cendio 2019-11-05 13:36:11 CET
Tested this for macOS on:

* Firefox 70
* Chrome 77
* Safari 13

It works fine on these browsers.