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

Can't use triggerEvent on a disabled element #1187

Open
lougreenwood opened this issue Jan 27, 2022 · 7 comments
Open

Can't use triggerEvent on a disabled element #1187

lougreenwood opened this issue Jan 27, 2022 · 7 comments

Comments

@lougreenwood
Copy link

I'm trying to test that a disabled button displays a tooltip when hovered, but it seems that triggerEvent won't allow this.

Can not triggerEvent on disabled [object HTMLButtonElement]

Seems this rule is overly strict?

@ro0gr
Copy link
Contributor

ro0gr commented Jan 28, 2022

I've created a quick reproduction https://codepen.io/ro0gr/pen/qBVdRoo, and I'm really surprised that title is shown for a disabled button.

However, there is a bit inconsitent behavior between browsers. In case of Firefox, a button is able to handle mouseover. While in Chrome event listeners don't react. It might mean that disabled + "events based logic" can't be implemented reliably(cross-browser).

Can you elaborate more on your exact use case please? Is it a custom tooltip element(cause I don't think it's possible to test native tooltips appearance)? Which events does your tooltip rely on?

@lougreenwood
Copy link
Author

lougreenwood commented Jan 28, 2022

Thanks @ro0gr, sure - an example of our use case looks something like:

<TooltipDecorator @tooltipText="bla" @showTooltip={{true}}>
    <button disabled={{@disabled}}>hello</button>
</TooltipDecorator>

So basically, we have this re-usable component which we wrap around elements to add a tooltip to them. In this case the button element itself doesn't have a tooltip, but rather, hovering it causes the tooltip on the parent wrapping TooltipDecorator to display.

The implementation of TooltipDecorator looks something like this:

{{#if @showTooltip}}
<span
      data-test-tooltip-decorator-tooltip
      aria-label={{translate-newlines @tooltipText}}
      class="tooltip {{@verticalPosition}}"
      ...attributes
>
  {{yield}}
</span>
{{else}}
    {{yield}}
{{/if}}

One workaround is that I could hover the decorator instead of the button - but that feels a bit too close to testing an implementation detail and I'd prefer to just trigger a mouseover or similar event on the disabled button to test that a tooltip is shown.

Which events does your tooltip rely on?

Looking at the code above, seems there is no JS used to display the tooltip and instead it uses aria-label to display the styled tooltip.

@MelSumner
Copy link
Contributor

👋 From an accessibility perspective, if an interactive element is disabled, a triggerEvent should not be allowed. If you want to explore some alternative UX solutions, I'd be happy to discuss further- check out the #topic-a11y channel in Discord.

@ro0gr
Copy link
Contributor

ro0gr commented Jan 28, 2022

Now I see, it's probably achieved via hover pseudo class, which propagates from disabled button to a decorator.
However, I believe it won't be possible to emulate this via JS https://www.w3.org/TR/DOM-Level-3-Events/#trusted-events

So, if I don't miss smth, interacting with a TooltipDecorator element seems reasonable to me.

@MelSumner
Copy link
Contributor

@ro0gr how would you access it as a keyboard-only user?

@ro0gr
Copy link
Contributor

ro0gr commented Jan 28, 2022

@MelSumner sorry, not sure if I follow your question, but as a keyboard user I'd probably use Tab or vim flavoured keybindings.

I mean I approach this issue from the low level testing perspective.

Seems this rule is overly strict?

as I can see now, there is still no point to make it less restrictive, cause I can not see any practical value for it.

@jrmlt
Copy link

jrmlt commented Nov 29, 2024

Adding to the discussion, I believe triggerEvent is too restrictive if it forbids all events on a form control with the disabled attribute. While the specification only mentions "click events" and MDN refers to "browsing events," all browsers currently allow mouse tracking events, such as mouseenter and mouseleave, to trigger on disabled controls. Additionally, there are events unrelated to user interaction, like transitionend and animationend.

Beyond known events, there's also the case of CustomEvent, which is entirely valid in browsers but is currently blocked by triggerEvent.

Maintaining a comprehensive list of forbidden or allowed events might not be practical or sustainable. However, I suggest providing testers with an option to trigger events on disabled elements if necessary. For instance, a force argument could be introduced to bypass this disabled check.

Proposed PR #1521.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants