[macos] Opening the "Command + Tab" App Switcher then clicking an a Winit window sometimes incorrectly generates a window event with key code "A"

[AlexisDeschamps]

What happens:

Opening the macOS App Switcher and then clicking on an app with a Winit window seems to sometimes incorrectly generate a window event with the virtual keycode "A" even though the key "A" was never touched.

How to reproduce the issue:

1. Run the example "window" ($ cargo run --example window)
2. Start pressing the Command key (⌘) and do not release it
3. Press and then release the Tab key (to open App Switcher)
4. Click on any other app that isn't the Winit window (e.g. Finder)
5. Press and then release the Tab key (to open App Switcher)
6. Click on the app that is the Winit window
7. Repeat steps 3 to 6 until the following happens: a window event is generated with the following data:

KeyboardInput {
    device_id: DeviceId(DeviceId), 
    input: KeyboardInput {
        scancode: 0,
        state: Pressed,
        virtual_keycode: Some(A),
        modifiers: LOGO,
    },
    is_synthetic: false,
}

What should happen:

I am not exactly sure what is happening, but I would expect one of the following two behaviors:
A: no window event is generated.
B: a "Pressed" window event is generated with the virtual key code of the Command key (⌘) used to open the App Switcher (and should still be held when the Winit window is opened). I think this might be LWin or RWin.

I think behavior "A" might be preferable since an event for the Command key (⌘) being pressed was already correctly generated after step 2.

Extra infomation:

The current behavior seems a bit inconsistent. It might take multiple repetitions of steps 3-6 before the bug occurs.

I delved a bit into the code and it seems the following is happening:

1. Sometimes, after step 6, the function flags_changed is fired.
2. The third modifier_event if let check with NSCommandKeyMask ends up evaluating to true (L757).
3. Inside modifier_event, the function get_scancode returns 0 for the event (L288).
4. The scancode 0is converted to VirtualKeyCode::A in scancode_to_keycode.

It seems Cocoa might be incorrectly reporting 0 as the scancode for the event, even though 0/A was never touched.

In terms of a Winit code solution, could we return None in modifier_event if the scancode is 0 since the associated keycode should not normally be able to trigger a modifier_event?
Example code:

let scancode = get_scancode(ns_event);
if scancode == 0x00 {
    return None;
}
let virtual_keycode = scancode_to_keycode(scancode);

This way, no event is generated as suggested in behavior "A". This is how I fixed the issue for myself locally.

Also, we might be able to file a bug for Apple/Cocoa.