fix(accordion): prevent opening of readonly accordion using keyboard #28865
Conversation
| await expect(accordion).toHaveClass(/accordion-collapsed/); | ||
| }); | ||
|
|
||
| test('should not open accordion via keyboard navigation when group is disabled', async ({ page, browserName }) => { |
There was a problem hiding this comment.
I believe pressing "Enter" on an interactive element will also dispatch a click event, so testing that the accordion does not expand on click should be sufficient here (i.e. we don't need to test click and Enter)
There was a problem hiding this comment.
That's not what I'm seeing. If I revert the bugfix I made in this PR and run the tests, the "should not open accordion via keyboard navigation when accordion is readonly" test fails, and no other tests fail. This is what we expect, since this is the one case this PR addresses. The other tests I added are for behavior that was already correct, but didn't have test coverage.
If the keyboard & mouse tests are redundant with each other, I would expect either both to pass or both to fail in any situation.
Put another way: if I removed the keyboard tests (which I think is what you're suggesting), all the tests would pass without my bugfix being applied.
There was a problem hiding this comment.
Oh yes I see what you are saying! In main all we do is set pointer-events: none on the header which prevents click events. But we never disable the underlying element, so you can still tab to an ion-item and then hit "Enter".
Keeping these tests make sense 👍 Thanks for clarifying
Issue number: resolves #28344
What is the current behavior?
When an Accordion is inside an Accordion Group, and the Accordion Group is enabled and not readonly but the Accordion is disabled and/or readonly, it is possible to navigate to the accordion and open it using the keyboard. This should not be allowed, just like opening it on click is not allowed.
What is the new behavior?
Does this introduce a breaking change?
Other information