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.

Sign up for GitHub

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

Jump to bottom

[Bug]: aria-disabled is not handled correctly in click() or toBeDisabled assertion #31439

Closed
d4rky-pl opened this issue Jun 25, 2024 · 8 comments
Closed

[Bug]: aria-disabled is not handled correctly in click() or toBeDisabled assertion #31439

d4rky-pl opened this issue Jun 25, 2024 · 8 comments
Labels
open-to-a-pull-request The feature request looks good, we are open to reviewing a PR P3-collecting-feedback

Comments

@d4rky-pl
Copy link

Version

1.45.0

Steps to reproduce

  1. Clone my repo at https://github.com/d4rky-pl/aria-disabled-repro
  2. Run npm install
  3. Run npx playwright test tests/aria-disable.spec.ts

Expected behavior

According to the documentation of toBeDisabled:

Ensures the Locator points to a disabled element. Element is disabled if it has "disabled" attribute or is disabled via 'aria-disabled'. Note that only native control elements such as HTML button, input, select, textarea, option, optgroup can be disabled by setting "disabled" attribute. "disabled" attribute on other elements is ignored by the browser.

Which sounds like the aria-disabled="true" attribute should be respected on all elements (and disabled attribute only on the listed ones). This is not the case here and both .click() ignores the attribute and .toBeDisabled treats this element as enabled.

Actual behavior

Either the behaviour should be fixed and elements with aria-disabled should be treated as disabled for all intents and purposes of what "disabled" means in Playwright, or the documentation should be adjusted to state clearly that disabled state is only supported for HTML form elements.

Additional context

No response

Environment

System:
    OS: macOS 14.4
    CPU: (12) arm64 Apple M2 Max
    Memory: 88.67 MB / 32.00 GB
  Binaries:
    Node: 20.13.1 - ~/.asdf/installs/nodejs/20.13.1/bin/node
    npm: 10.5.2 - ~/.asdf/plugins/nodejs/shims/npm
    bun: 1.0.6 - ~/.asdf/shims/bun
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: ^1.45.0 => 1.45.0
@pavelfeldman
Copy link
Member

There is no indication on this <div> that it is in fact a button and that it is disabled. Playwright will do what the user would in this case - click the element.

@d4rky-pl
Copy link
Author

@pavelfeldman if that's the intended behaviour then it's fine and this bug is just a documentation improvement request then 🙂

@pavelfeldman
Copy link
Member

@d4rky-pl do you want to send a PR?

@pavelfeldman pavelfeldman added open-to-a-pull-request The feature request looks good, we are open to reviewing a PR P3-collecting-feedback labels Jun 25, 2024
@hex0cter
Copy link
Contributor

hex0cter commented Jul 4, 2024 •
edited
Loading

I ran into the same issue today. The toBeDisabled problem is solved by adding role="button" in the html element. Thanks for the nice repo @d4rky-pl!

@d4rky-pl
Copy link
Author

d4rky-pl commented Jul 5, 2024

@pavelfeldman I would love to send a PR but I'm going to need more details on what's the expected behaviour. When is aria-disabled taken into an account? What other attributes make Playwright consider it?

@hex0cter
Copy link
Contributor

hex0cter commented Jul 5, 2024

I have another example where toBeDisabled doesn't work. Here is the html:

<html lang="en">
<body>
  <label>
    <ul role="menu">
      <li role="menuitem" id="foo" aria-disabled="true">
        AAAAA
      </li>
    </ul>
  </label>
</body>
</html>

and here is the test:

test('aria-disabled is not ignored', async ({ page }) => {
  await page.goto('http://localhost:57487/tests/');
  await expect(page.locator('#foo')).toBeDisabled();
});

The error I got is:

Error: Timed out 5000ms waiting for expect(locator).toBeDisabled()

    Locator: locator('#foo')
    Expected: disabled
    Received: enabled
    Call log:
      - expect.toBeDisabled with timeout 5000ms
      - waiting for locator('#foo')
      -   locator resolved to <li id="foo" role="menuitem" aria-disabled="true">↵        AAAAA↵      </li>
      -   unexpected value "enabled"

Removing the label tag in the parent node solved the problem. I'd really like to know how this is supposed to work.

@pavelfeldman pavelfeldman mentioned this issue Jan 7, 2025
Merged
@pavelfeldman
Copy link
Member

@hex0cter your issue is real, but unrelated, I'll handle it separately.
@d4rky-pl we respect ARIA spec, so it would be best to say that we work by ARIA spec.

@pavelfeldman
Copy link
Member

Closing as per above as having no action item for the team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
open-to-a-pull-request The feature request looks good, we are open to reviewing a PR P3-collecting-feedback
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@d4rky-pl @pavelfeldman @hex0cter