-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Security Solution] Fix some Prebuilt Rules Cypress tests not running in CI #191978
Merged
nikitaindik
merged 9 commits into
elastic:main
from
nikitaindik:cypress-tests-not-running-on-ci
Sep 13, 2024
+643
−680
Merged
Changes from 4 commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
e7f69bf
Rename `update_workflow.ts` -> `update_workflow.cy.ts`
nikitaindik 91a7f0e
`prebuilt_rules_preview.cy.ts`: move `@ess` and `@serverless` tags to…
nikitaindik 08c8ee8
Update element selectors to fix tests in `prebuilt_rules_preview.ts`
nikitaindik fb10273
Remove flyout backdrop to let the user switch between table items
nikitaindik 477898f
Merge branch 'main' into cypress-tests-not-running-on-ci
nikitaindik a7dfa6a
Merge branch 'main' into cypress-tests-not-running-on-ci
nikitaindik 4f91329
Merge branch 'main' into cypress-tests-not-running-on-ci
nikitaindik d1cadfa
Revert the flyout backdrop change, remove the related test
nikitaindik 60e5779
Merge branch 'main' into cypress-tests-not-running-on-ci
nikitaindik File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that this is the correct change. This table is partially (or completely) covered by the open
Flyout
, which means, from ana11y
perspective, we should not allow setting focus on it.Let's ask EUI. @cee-chen / @1Copenut please give us your input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the importance of the functionality for quick preview, but also I think we need to follow a consistent style for when it is appropriate to use
ownFocus
and when it is not.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nikitaindik I have the same concern. It's better to follow current UX across Kibana. I'm pretty sure the test you mentioned was written some time ago when the flyout didn't own focus by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EuiFlyout does set
ownFocus={true}
by default, so unless this component now explicitly setsownFocus={false}
this component should be behaving the same way as before.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry disregard my previous unhelpful comment, I was looking only at the line highlighted and not at the full diff, I see this is setting
ownFocus={false}
.ownFocus={false}
flyouts still move/trap focus, so the flyout content still remains accessible for keyboard users, although the content below it does not: https://eui.elastic.co/#/layout/flyout#without-ownfocusAlexey, does the above documentation help explain
ownFocus
usage?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cee-chen Yep, that's exactly what I mean. That case doesn't seem like something where we should set
ownFocus={false}
. The default behavior will provide the best UXThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your input folks! I have tried both options myself and found that when tabbing using the keyboard the focus seems to behave the same. With either
ownFocus={false}
orownFocus={true}
it stays within the flyout and top page menu. Please tell me if I misunderstood your concern.Also I have discussed this with our PO (@approksiu) and design team today, showed them both options - with and without the backdrop. And we have concluded that for our use case (quickly switching between rules) it would be desirable if there's no backdrop and table items are still clickable with a mouse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I certainly support the unification of UX, but this is your decision. Please keep in mind that this will lead to the following issues:
I'm not insisting, I just want to highlight and explain why we removed
ownFocus={false}
@approksiu just fyi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for highlighting these 2 issues @alexwizp! I have discussed these with the team and we've decided to revert to the default behaviour (with the dark backdrop). Made the change in this commit: d1cadfa