Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EuiPopover] Removed false as an option for initialFocus, removed unnecessary focus logic #6044

Merged
merged 6 commits into from
Jul 20, 2022

Conversation

cee-chen
Copy link
Contributor

@cee-chen cee-chen commented Jul 11, 2022

Summary

See: #5977 (comment)

I think what's happening is actually due to react-focus-on's autoFocus behavior. If I set EuiFocusTrap's autoFocus={false} when initialFocus={false} - focus is removed completely from the document. This is actually technically 'correct' behavior if a focus trap is enabled on the popover - because the toggling button is outside the popover, focus actually shouldn't have remained on it.

I think the best way forward frankly (after #5784) is to remove initialFocus={false} as an option at all. It no longer really makes sense after its first implementation in #4768, since false/focusing the panel is basically the default at this point.

⚠️ The main fix is 4c9bac5, but I actually realized while testing more that there's some underlying / overlapping focus behavior going on.

I initially thought the initialFocus overrides were the issue (84fe068), but after some more testing I quickly realized the auto focus behavior is coming from EuiFocusTrap/react-focus-on/react-focus-lock itself.

After even more thinking, I realized there's a lot of overlapping logic between EuiPopover's updateFocus logic and the focus logic that comes OOTB with FocusTrap/focus-lock ... so I experimented with removing updateFocus completely (74e38dc) and bam - everything still works as-is 🙈

We should definitely test thoroughly considering EuiPopover's ubiquitousness. I'll make a QA list below:

QA

  • EuiTour (no change, ownFocus as false so initial focus was never set)
  • EuiColorPicker (no change, initialFocus is passed/set by this component)
  • EuiDatePicker (no change, focus remains on datepicker input but tabs to popover after)
  • EuiSuperDatePicker (no change, focuses popover panel)
  • EuiAutoRefresh (no change, focus works as before)
  • EuiSelectableTemplateSitewide (no change, ownFocus set by component)
  • EuiContextMenu (all Cypress tests passing)
  • EuiDataGrid (no change, focus works as before)
  • EuiSearchBar (no change, focus works as before)
  • EuiNotificationEvent (no change)
  • Components using EuiInputPopover - will have no change as ownFocus is false on these
  • EuiComboBox does not actually use EuiPopover but its CSS classes / does not have its own focus state

Checklist

  • Checked in Chrome, Safari, Edge, and Firefox
  • Added or updated jest and cypress tests
  • Checked for breaking changes and labeled appropriately
  • Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

- [ ] Checked in both light and dark modes
- [ ] Checked in mobile
- [ ] Props have proper autodocs and playground toggles
- [ ] Added documentation
- [ ] Checked Code Sandbox works for any docs examples
- [ ] Updated the Figma library counterpart

cee-chen added 5 commits July 11, 2022 15:34
- since the panel popover is now always used as a default, false feels unnecessary - initialFocus should only be passed if something other than the popover parent should be focused
+ do not override to the panel if it's already set

+ update spec tests to check for `data-autofocus` to confirm that react-focus-on is being passed the correct `initialFocus` as expected
AFAICT, this is already being handled automatically by `EuiFocusTrap`, and works exactly as before / in Cypress, so I don't see the need for the extra focus logic
- now that EuiPopoverFocus no longer has an `updateFocus` method, it turns out the focus fighting is coming from the focus trap
@cee-chen cee-chen requested a review from thompsongl July 11, 2022 23:41
@cee-chen cee-chen marked this pull request as ready for review July 12, 2022 00:05
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_6044/

@thompsongl
Copy link
Contributor

After even more thinking, I realized there's a lot of overlapping logic between EuiPopover's updateFocus logic and the focus logic that comes OOTB with FocusTrap/focus-lock ... so I experimented with removing updateFocus completely (74e38dc) and bam - everything still works as-is 🙈

Dang that would be cool if we could outsource the focus logic. This is definitely a case of unintentional overlap. The EuiPopover logic was added when it used a different focus trap library and react-focus-on/lock has gotten even better in the last couple years.

Going to do some test on the various components tomorrow!

@thompsongl
Copy link
Contributor

Still doing manual testing but commenting to say that all instances of initialFocus=false in Kibana appear to just avoid focusing the first focusable element, so no changes will be necessary.

Copy link
Contributor

@thompsongl thompsongl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super happy about this 🙌

Ran through a bunch of components manually and found no focus regressions. Even the ownFocus=false scenario behaves as it did, which I had initial concerns about (I thought perhaps updateFocus still added focus, but it did not).

I wouldn't mind having one other person take a look, though, as this change has far-reaching implications. Also perhaps considering whether to not have this go into Kibana before 8.4 FF. cc// @chandlerprall

@cee-chen
Copy link
Contributor Author

Agreed on getting a second pair of eyes/QA, but I'd argue this PR has the same implications that #5784 does (less so because it doesn't actually affect functionality), which is already in Kibana 8.4. That being said I wouldn't rush to get it in before FF though, if it doesn't make it, it doesn't make it, not a big deal

@thompsongl
Copy link
Contributor

thompsongl commented Jul 14, 2022

I'd argue this PR has the same implications that #5784 does (less so because it doesn't actually affect functionality), which is already in Kibana 8.4

Yeah agreed. The only difference is Kibana teams have had 2 months to catch any bugs from #5784, whereas if this merged those teams would only have a couple days to catch regressions. More timing than severity was my point there.

@cee-chen
Copy link
Contributor Author

Gotcha, makes sense! PRs like this definitely make me wish we had the ability to run Kibana CI against EUI dev branches, their FTR tests are super robust and would def catch regressions. Maybe we can bribe the inestimable @kertal sometime? 😇

@chandlerprall
Copy link
Contributor

Very excited at the prospect of deleting this code! I'll take a pass, but may not be until next week. Having only skimmed the changes, I don't think there's a need to avoid 8.4.

@kertal
Copy link
Member

kertal commented Jul 19, 2022

Gotcha, makes sense! PRs like this definitely make me wish we had the ability to run Kibana CI against EUI dev branches, their FTR tests are super robust and would def catch regressions. Maybe we can bribe the inestimable @kertal sometime? 😇

Sounds like a very useful idea ... so the idea is planted 🪴 ... which is a start

@cee-chen
Copy link
Contributor Author

@chandlerprall Quick ping on QAing/approving this PR!

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Played with a number of popovers across the examples, making changes to / adding some initialFocus definitions and everything continues working as expected 🎉

@cee-chen
Copy link
Contributor Author

cee-chen commented Jul 20, 2022

Thanks Chandler!! Merging now. Just to confirm, it sounds like this PR won't be released in time for Kibana 8.4, which I'm personally totally fine with - let me know if anyone feels strongly otherwise!

@cee-chen cee-chen merged commit 7fb31f4 into elastic:main Jul 20, 2022
@cee-chen cee-chen deleted the popover/initialFocus branch July 20, 2022 17:24
kibanamachine added a commit to cuff-links/kibana that referenced this pull request Aug 12, 2022
* Upgrade to v62.0.3

* Update EUI i18n tokens

* Update html string snapshots

- Emotion CSS hash changed

* [EuiIcon] Update instances of `keyboardShortcut` icons to `keyboard`

* [EuiErrorBoundary] Update snapshots from Emotion conversion

* [EuiImage] Update snapshots, tests, and CSS to account for Emotion conversion

* [EuiImage][RTL] Fix test failures caused by EuiImage changes

* [EuiCommentList] Deprecate EuiCommentProps.type

* [EuiCommentList] Rename `timelineIcon` prop to `timelineAvatar`

- see elastic/eui#6071

* [EuiCommentList] Fix selectors deprecated by Emotion conversion

* [EuiPopover][EuiCommentEvent][Enzyme] Fix mounted test failures caused by Emotion conversions

- Mounting displays the Emotion wrapper with the data-test-subj on them - we need to specify the output div renders in order for text assertions to be correct

* [EuiPopover] Deprecate `initialFocus={false}` as an option

see elastic/eui#6044

* [EuiPopover] Rename `display=inlineBlock` to `inline-block`

- see elastic/eui#5977

* [EuiPopover] Update snapshots from Emotion conversion

* [EuiPopover] Replace deprecated `.euiPopover__panel-isOpen` class with new `[data-popover-open]` attribute

* [EuiPopover][RTL] Fix test failures caused by not waiting for EuiPopover animation/transition

* Skip failing a11y tests

- test w/ similar error already skipped in another test above
- requires closing the popover for next test to pass
- not sure why delete action is no longer available

* Fix failing Security Cypress tests

* Attempt to squash flaky FTR tests around Add Filter popover

Co-authored-by: Kibana Machine <[email protected]>
Co-authored-by: Jonathan Budzenski <[email protected]>
Mpdreamz pushed a commit to Mpdreamz/kibana that referenced this pull request Sep 6, 2022
* Upgrade to v62.0.3

* Update EUI i18n tokens

* Update html string snapshots

- Emotion CSS hash changed

* [EuiIcon] Update instances of `keyboardShortcut` icons to `keyboard`

* [EuiErrorBoundary] Update snapshots from Emotion conversion

* [EuiImage] Update snapshots, tests, and CSS to account for Emotion conversion

* [EuiImage][RTL] Fix test failures caused by EuiImage changes

* [EuiCommentList] Deprecate EuiCommentProps.type

* [EuiCommentList] Rename `timelineIcon` prop to `timelineAvatar`

- see elastic/eui#6071

* [EuiCommentList] Fix selectors deprecated by Emotion conversion

* [EuiPopover][EuiCommentEvent][Enzyme] Fix mounted test failures caused by Emotion conversions

- Mounting displays the Emotion wrapper with the data-test-subj on them - we need to specify the output div renders in order for text assertions to be correct

* [EuiPopover] Deprecate `initialFocus={false}` as an option

see elastic/eui#6044

* [EuiPopover] Rename `display=inlineBlock` to `inline-block`

- see elastic/eui#5977

* [EuiPopover] Update snapshots from Emotion conversion

* [EuiPopover] Replace deprecated `.euiPopover__panel-isOpen` class with new `[data-popover-open]` attribute

* [EuiPopover][RTL] Fix test failures caused by not waiting for EuiPopover animation/transition

* Skip failing a11y tests

- test w/ similar error already skipped in another test above
- requires closing the popover for next test to pass
- not sure why delete action is no longer available

* Fix failing Security Cypress tests

* Attempt to squash flaky FTR tests around Add Filter popover

Co-authored-by: Kibana Machine <[email protected]>
Co-authored-by: Jonathan Budzenski <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants