Do not throw an error when clicking on a disabled element

The current behavior of the click helper is to throw an error “Can not click disabled element” when trying to do so.

The problem is that clicking on a disabled element is something that a user is perfectly capable of doing. Simulating this behavior in an acceptance test should not be punished.

When I make my test click a disabled button, I expect the test not to crash. I expect the test to proceed and to assert that nothing has changed.

Instead of clicking a disabled element, @ember/test-helpers forces me into asserting that the element contains the disabled attribute. This has two problems:

1. It’s not the same thing. Asserting for an element’s attribute does not guarantee lack of behavior on click.
2. The Cucumber BDD framework has a test matrix feature (aka Examples aka Where) which is intentionally limited: it does not have loops and conditionals for the sake of simplicity and readability. The fact that I need to use a different assertion depending on whether the button is disabled or not — makes it impossible to put it into a Cucumber test matrix.

[jfdnc]

Fwiw, I’ve come across the error-throw-on-disabled behavior that was added in https://github.com/emberjs/ember-test-helpers/pull/778 and at first found it confusing, but agree generally with the practicality it provides for tracking down invalid results (we don’t use the mentioned BDD methodology, and my first run-in with this error throw resulted in an immediate code change because it pointed out an actual code issue).

I am also sympathetic to what @lolmaus is saying here, and it was even pointed out in the error-adding PR that opt-in behavior might be a sensible tool to add here (along with documentation of course!), and that different browser versions can handle event firing on disabled differently, so I doubt that the testing practicality vs purity of the HTML spec conversation even has an exact answer.

For general flexibility, and considering the BDD community, whatever their size may be, it would be nice to have individual opt out like click(element, { forceInteract: true }) for these things, and/or a mechanism to disable error-throwing like setupForceElementInteract(hooks, ['click', ...]) that could allow the consumer to explicitly acknowledge they want to pass through on these empty interactions, which would avoid having to forceInteract: true on every single case like in the combination matrix example above.

I’ll finish by recommending a great book I’ve read recently, A Philosophy of Software Design. The related bit here is a focus on allowing the most common useful cases for invoking a module to be the defaults. For these test helpers, there was already a precedent to error on invalid focusing, and I’d say most consumers (including my team) actually benefit from that general fail-fast behavior being the default, and would not want to have to redecorate all of our test imports to opt back in to that sensible (for test practicality) default behavior.

[stefanpenner]

The spec does have a concrete opinion on this: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#enabling-and-disabling-form-controls:-the-disabled-attribute

I believe that suggests the existing behavior is alright, and it is likely appropriate to close this issue. But WDYT? Please let me know if my reading on ^^ is in error