[Bug]: useFocusRects code triggers on keyboard/mouse behavior outside of Fluent components

[kelseyyoung]

Library

React / v8 (@fluentui/react)

System Info

System:
    OS: Windows 10 10.0.19044
    CPU: (12) x64 Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz
    Memory: 16.29 GB / 31.90 GB
  Browsers:
    Chrome: 101.0.4951.67
    Edge: Spartan (44.19041.1266.0), Chromium (101.0.1210.53), ChromiumDev (91.0.838.3)
    Internet Explorer: 11.0.19041.1566

Are you reporting Accessibility issue?

no

Reproduction

https://codepen.io/kelseyyoung/pen/qBxKaEp

Bug Description

Actual Behavior

In the codepen linked there are two Fluent Buttons followed by non-Fluent HTML elements. Buttons include the code from useFocusRects/the <FocusRects> component in BaseButton.tsx

    return (
      <>
        {Content}
        <FocusRects />
      </>
    );

This code will toggle two classnames on the body element of the page, ms-Fabric--isFocusVisible and ms-Fabric--isFocusHidden, when toggling between mouse and "focus keyboard" events. However, these handlers are attached to the window, and so this code fires on events not using Fluent components. To mimic this behavior in the codepen, the repro steps are:

1. Place your mouse cursor inside the input box via click
2. Hit the right or left arrow key
3. Observe the classname on the body of the codepen changes the classname

(Gif below shows the classname changing while toggling between mouse clicks and arrow keys)

Changing this classname causes a style recalculation in the browser despite these events happening on non-Fluent components. If no Fluent components are involved, the code in useFocusRects shouldn't need to fire

Expected Behavior

We believe the behavior of useFocusRects could change in these ways, or other equivalent solutions:

1. Constrain its behavior to only trigger on events where Fluent components are involved (either by default or
2. Attach the classnames to a more scoped element instead of the body of the entire document

Logs

No response

Requested priority

Normal

Products/sites affected

Office Online

Are you willing to submit a PR to fix?

no

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[gouttierre]

@kelseyyoung - Thanks for filing this issue with us. To set expectations the developers will review this issue once capacity allows.

@bsunderhus - Would you be able to confirm if this is a regression, or if this behavior is an issue?