-
Notifications
You must be signed in to change notification settings - Fork 401
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
toBeDisabled
should match against web components / custom elements
#367
Comments
Are these still form elements though? As far as I remember, the disabled role is specifically for form elements, or at least our usage of it. |
They can be! In the example described above, We resorted to use |
i had the same problem. I will create a new issue with details. |
I solved the problem. |
This has been fixed by #368, thanks all! |
@testing-library/jest-dom
version: 5.12.0@testing-library/react
version: 11.2.7node
version: 14.16.1yarn
version: 1.22.5Relevant code or config:
I used
@cds/core
(Clarity) which is a library of web components +@cds/react
which is a bunch of React wrappers for said web components. Pretty much everything else is default config.What you did:
This is the failing test:
CdsButton
under the hood renders acds-button
web component. It uses an async test because Clarity fills a bunch of props asynchronously, includingdisabled
,aria-disabled
,role
, etc.What happened:
Text version
Reproduction:
A minimal reproduction repo can be found at https://github.com/astorije/repro-web-component-tobedisabled.
Steps to reproduce:
yarn install
yarn test
Problem description:
I scratched my head for a bit as I initially thought Clarity was doing something unwanted, but as soon as I opened the
toBeDisabled
source, I realized that it filters again a hardcoded list).Since no web components would ever be found in this list,
toBeDisabled
would not support them.Suggested solution:
The doc says:
However, that WHATWG spec lists an extra bullet point that is missing from that list:
So the hardcoded list needs to support web components aka custom elements.
According to MDN:
So my suggested solution is to add elements whose tags contain a hyphen to the list of elements that can actually be disabled.
The text was updated successfully, but these errors were encountered: