Commit bf75f52
UI/AppKit: Store the original key-down event for WebContent processing
When a shortcut is an alternative key, macOS first fires a key event for
the primary key. Then if it is not handled, it fires an event for the
alternative key. For example, we see these two events in a row when we
press cmd and =/+:
NSEvent: type=KeyDown flags=0x100108 chars="=" keyCode=25
NSEvent: type=KeyDown flags=0x100108 chars="+" keyCode=24
For dead key processing, we don't handle these events right away. By the
time we get to doCommandBySelector, when we call [NSApp currentEvent],
we see the following events:
NSEvent: type=KeyDown flags=0x100108 chars="=" keyCode=24
NSEvent: type=AppDefined flags=0
The AppDefined event is internally posted by our event loop. So it seems
we cannot rely on currentEvent being the key-down event we are looking
for.
Instead, we can store the key-down event that we last saw.1 parent 934817d commit bf75f52
1 file changed
+17
-10
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
62 | 62 | | |
63 | 63 | | |
64 | 64 | | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
65 | 68 | | |
66 | 69 | | |
67 | 70 | | |
| |||
842 | 845 | | |
843 | 846 | | |
844 | 847 | | |
| 848 | + | |
| 849 | + | |
| 850 | + | |
| 851 | + | |
| 852 | + | |
| 853 | + | |
| 854 | + | |
| 855 | + | |
| 856 | + | |
| 857 | + | |
| 858 | + | |
845 | 859 | | |
846 | 860 | | |
847 | 861 | | |
| |||
1072 | 1086 | | |
1073 | 1087 | | |
1074 | 1088 | | |
| 1089 | + | |
1075 | 1090 | | |
1076 | 1091 | | |
1077 | 1092 | | |
| |||
1138 | 1153 | | |
1139 | 1154 | | |
1140 | 1155 | | |
1141 | | - | |
1142 | | - | |
1143 | | - | |
1144 | | - | |
1145 | | - | |
| 1156 | + | |
1146 | 1157 | | |
1147 | 1158 | | |
1148 | 1159 | | |
1149 | 1160 | | |
1150 | | - | |
1151 | | - | |
1152 | | - | |
1153 | | - | |
1154 | | - | |
| 1161 | + | |
1155 | 1162 | | |
1156 | 1163 | | |
1157 | 1164 | | |
| |||
0 commit comments