cibernox / ember-native-dom-helpers

Test helpers for your integration tests that fire native events

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Clicking on disabled input checkbox modify checked value

livet01 opened this issue · comments

I create a component my-input-component.hbs:

<input type="checkbox"
   checked={{checked}}
   disabled={{disabled}}>

and I add a integration test:

import { click, find } from 'ember-native-dom-helpers';
//...
test('disabled state', async function(assert) {
   await render(hbs`{{my-input-component disabled=true checked=false}}`);
   assert.notOk(find('input[type="checkbox"]').checked);

   await click('input[type="checkbox"]');
   assert.notOk(find('input[type="checkbox"]').checked);
});

The second assert.notOk fails, find('input[type="checkbox"]').checked returns true.

If I replace click helper by something like that, it's working:

Ember.run(() => document.querySelector('input[type="checkbox"]').click());

Do you have any idea about why click has this behaviour? Thanks.

Not really, it should behave the same. Is the checkbox properly disabled?

Yes, the checkbox remain disabled.

When I try to build my own click event:

var event = document.createEvent('MouseEvents');
event.initMouseEvent('click');
var element = document.querySelector('input[type="checkbox"]');
console.log(element.checked, element.disabled); // false true

element.dispatch(event);
console.log(element.checked, element.disabled); // true true

I can reproduce the behaviour. click event doesn't seem to keep the native behaviour of the checkbox. 🤔

That is interesting. I don't know why firing a mouse event on a disabled checkbox is different that calling .click() on it, but I do think it's something that should be fixed.

Can you only verify that this is not a browser bug by testing it on firefox and safari or edge? If so, this must deserve some special case.

Interesting, on firefox I can't reproduce the bug and my tests are green.

More or less what I was expecting. This totally looks like a browser bug to me. What about safari and edge?

Bug is here on Safari (so webkit) and not here on Edge.

So we have a Chrome/Safari VS firefox/edge discrepancy in hands. I think we should report it. I think that the firefox/edge behaviour is the correct one.

I'll see to report that to Webkit.

But, do you think it worth to fix it on this repo?

I think I wouldn't oppose if the fix is reasonably simple and we leave a comment linking to the bug-report, so we can remove the hack once it's fixed.