cc @nhunzaker

Oops, I meant to cc @jquense

Yes this is expected and unavoidable to some extent. React dedupe change and input events so they don't fire too often, in this case even tho you intentionally want to trigger the event react is swallowing it because it the input value has not changed. you can use the SimulateNative helper to get the behavior your looking for. Tho that will break again in v16

What's the workaround?

I guess this is grey area and unclear if we supported this. As @jquense mentioned you can use SimulateNative in the meantime. After 16, feel free to file a new issue and we'll look at other ways of handling this.

cypress-io/cypress#536 from an additional use case affected similarly. They outline their long term "workaround" as well.

I do think this falls into a gray area, complete transparent DOM interoperability is always nice but hard to do and potentially limiting give Reacts model for targeting and it :/

@jquense Btw. this happens no matter if the value is changed or not - I probably should've included that info in this issue.

I understand that this is unexpected (the event should not be swallowed by React if the value has changed), so I'm including an updated example: https://jsfiddle.net/6bv1581z/1/

I'll need some time to process the use case in cypress (esp. the part about the setters - don't really know what the spec says about this), so I'm not strongly opinionated for now.

In any case, the simulated thing seems to be working for now and the code that's using it waits for a rewrite, so that might be turned into a non-issue for me.

I'm just wondering - won't this affect the ability to make integration tests for React-based apps using the DOM api?

Sorry if that's all answered in the linked thread, I have yet to connect the dots.

Just leaving a solution for future reference (checked in Edge 15, IE 11, FF 53, Chrome 59):

function setNativeValue(element, value) {
  const valueSetter = Object.getOwnPropertyDescriptor(element, 'value').set;
  const prototype = Object.getPrototypeOf(element);
  const prototypeValueSetter = Object.getOwnPropertyDescriptor(prototype, 'value').set;
  
  if (valueSetter && valueSetter !== prototypeValueSetter) {
  	prototypeValueSetter.call(element, value);
  } else {
    valueSetter.call(element, value);
  }
}

Use it like so:

setNativeValue(textarea, 'some text');
textarea.dispatchEvent(new Event('input', { bubbles: true }));

Btw. this happens no matter if the value is changed or not - I probably should've included that info in this issue.

Yes, i also left that bit off because its a bit hard to explain, but React tracks manual DOMNode.value changes as well, so when you do input.value ='foo' and then dispatch a change event React sees two discreet moments there, the first change and then the change via the event, so when your input event fires the value is still 'foo' and React says "I already know about that that value so this must be a duplicate"

I'm just wondering - won't this affect the ability to make integration tests for React-based apps using the DOM api?

It shouldn't, if you are using something like Selenium, which fires "real" events when you ask it too, vs "fake" ones we can fire in the DOM. Comparative tools like Cypress or nightmare, etc should use workarounds that mimic the real browsers behavior so if something breaks (as in this case) it was more of a bug in Cypress :)