bug(cdk/a11y): [Safari] [Chrome] [MacOS] FocusMonitor improperly identifies subsequent right mouse clicks as keyboard focus origin

[zelliott]

This was found while stress-testing #22489.

Reproduction

1. Go to https://material.angular.io/cdk/a11y/overview#focusmonitor on Chrome
2. Scroll to the "Monitoring focus with FocusMonitor" example.
3. Right click on "Child Button 2". Mouse focus should be detected.
4. Now right click on "Child Button 1". Observe that keyboard focus is incorrectly detected.

Expected Behavior

I expect mouse focus to be detected.

Actual Behavior

Keyboard focus was detected.

Cause

The second right-click event, on Chrome, is emitted with event.buttons === 0. This causes the isFakeMousedownFromScreenReader function to determine that it's a fake mousedown, which causes FocusMonitor to attribute it as keyboard instead of mouse.

One idea: Can we update the isFakeMousedownFromScreenReader method to instead look at the event.offsetX and event.offsetY of the mouse event? That might be a better heuristic. I don't have the context/history into this method though. @crisbeto @jelbourn

Environment

• Angular: Latest
• CDK/Material: Latest
• Browser(s): Chrome 89.0.4389.128
• Operating System (e.g. Windows, macOS, Ubuntu): macOS BigSur

[crisbeto]

It works correctly for me and I'm seeing event.buttons === 2 for right clicks. Could it be an OS issue?

[zelliott]

Works fine for me as well on Windows. It also works fine for me on FF + MacOS.

[zelliott]

Another reason we might want to update this heuristic to use the event coordinates instead: It's possible to control your mouse pointer with AT software like VO and Mouse Keys. For example, you can trigger a mouse click at your mouse's current coordinates using VO with VO + Shift + Space. Note that this is different from VO + Space which triggers the default action of the element in the virtual cursor. What input modality do we consider the former interaction? I know we consider the latter to be keyboard, but there's an argument to be made that the former interaction should be attributed as mouse. We can do this by updating our heuristic to use the event coordinates.

Additionally, you can trigger mouse clicks with NVDA with NVDA + [. These clicks appear to be completely normal mouse events (they have event.buttons === 1 and legitimate offset coordinates. Given we currently detect these NVDA-triggered mouse clicks as mouse, there's an argument that we should detect VO-triggered mouse clicks as mouse as well.

[jelbourn]

My inclination would be to err on the side of showing the focus treatment whenever there's uncertainty. The only reason we avoid showing the focus treatment for pointer interactions is because it doesn't look as "nice"; showing the focus treatment in cases where it's not strictly necessary is a pretty minor issue in my thinking. As for what the right behavior is, I think ideally we could match the behavior of :focus-visible, whatever that is for this case.

[zelliott]

As for what the right behavior is, I think ideally we could match the behavior of :focus-visible, whatever that is for this case.

I did some quick testing:

• Subsequent right clicks disable :focus-visible (as expected, of course).
• Triggering a mouse click with VO (i.e. with VO + Shift + Space) disables :focus-visible.
• Triggering an element's default action in VO's virtual cursor (i.e. with VO + Space) is ignored by :focus-visible (i.e. it remains what it currently is).

Thus, my proposal seems to align with :focus-visible's behavior.