Keyboard interactions have strange impacts

[lache-melvin]

Describe the bug

Related: #71

On the events list view, when filtering by a notification config, any interaction with the keyboard while the modal is open was causing the filter button to be in focus when it closes??? i.e. if you scroll and click, it's fine, but if you search and then click, this happens:

This seems like I'm being summoned to open the modal again... I tried a couple of things but not sure why it's only after keyboard interactions.

For now the button has had its ripple effect disabled (disableRipple prop added to it) but this is a shame from an accessibility perspective/if you like to tab around to navigate your browser.

On a bigger level, I think all the wrapping we've done of the base MUI components is starting to affect the builtin behaviours (I'm thinking of that #71 issue too now...) Or perhaps we aren't using the components in the right node structure, like it needs a parent of some kind that it doesn't have?? Needs some research...

Expected behaviour

Keyboard and mouse based interactions should have the same outcome...

Additional context

[EthanMcQ-TMF]

This is (basically) correct behaviour. Closing a modal should return focus to the inciting element, this is happening whether you use keyboard or mouse. It's just that when you use the keyboard to interact focus-visible is set to active.

It looks like MUI isn't correctly updating focus-visible on the main app when we click one of the filter options. I suspect this is because we're closing the modal outside of its usual buttons context, since it does correctly update if you use the cancel button. (It looks like something doesn't play well with focus on the autocomplete list we use in this modal. Since the modal also doesn't respect ESC to quit while you're focused on the autocomplete, but if you tab over to the cancel button ESC works all of a sudden, strange 🤔)