selectOptions triggers change twice

Reproduction example

https://codesandbox.io/s/gracious-tess-xtusee?file=/src/App.test.js

Prerequisites

1. Render two <select onChange={handleChange}> elements
2. call selectOptions for one, then another (or call for one then do userEvent.tab())

Expected behavior

onChange is called one time

Actual behavior

onChange is called twice. First time when selecting option, second time when changing option for other <select/> or tabbing out.

User-event version

14.0.4

Additional context

This was not a problem in v13: https://codesandbox.io/s/crazy-bas-1vvrhy?file=/src/App.test.js

my current walk around to be able to update to v14 is:

function selectOptions(select: HTMLElement, option: string) {
  fireEvent.change(
    select,
    { target: { value: (within(select).getByText(option, { collapseWhitespace: true, selector: 'option' }) as HTMLOptionElement).value } }
  );
}

[ph-fritsche]

Thanks for the report.

One is dispatched in the utility:

user-event/src/utility/selectOptions.ts

Line 68 in 6d36828

this.dispatchUIEvent(select, 'change')

The other one is from the automatic change event on blur:

user-event/src/document/index.ts

Lines 43 to 56 in 6d36828

	document.addEventListener(
	'blur',
	e => {
	const el = e.target as HTMLInputElement
	const initialValue = getInitialValue(el)
	if (typeof initialValue === 'string' && el.value !== initialValue) {
	dispatchUIEvent({} as Config, el, 'change')
	}
	},
	{
	capture: true,
	passive: true,
	},
	)

https://codesandbox.io/s/epic-tereshkova-wqodx2?file=/src/App.js

[ph-fritsche]

The change event occurs when a new value is committed.
For <input type="checkbox">, <input type="radio">, <input type="file">, <select> this is when the user interaction changes the value.
For date-related input types it looks like only a date selected per date-picker should result in an instant commit. The behavior on edits per e.g. keyboard input might be inconsistent.

Other editable elements with a value property issue a change event when the value was changed and the element loses focus.

But it looks like there was a false assumption on when the browser registers the "initial value" to determine if the value was changed:
While programmatic changes to the value reset the UI value, they don't reset the initial value. They are just ignored in that regard.
The value is compared to the value at the time of the first user input (not the time of the element gaining focus).
(#703 , #747 )

So we might be able to hit two birds with one stone here:
If we set the initial value when we setUIValue, we fix the additional change event when the value is changed by other means than an uncommitted user input - and we also fix missing change events when there is a programmatic change after user input.

document.body.innerHTML=`<input/>`
const input = document.querySelector('input')
input.addEventListener('change', console.log)
input.addEventListener('keydown', e => { if(e.key === 'x') {
  e.target.value += 'X'
  e.preventDefault()
}})

[github-actions]

🎉 This issue has been resolved in version 14.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

Can confirm it fixed broken tests and didn't introduce any new ones. Thanks for fast fix :)

[vcardillo]

Maybe there is a regression? I am currently running into this issue on the latest version, 14.6.1.

await userEvent.selectOptions(select, '2')
await userEvent.selectOptions(select, '2')

On a select box such as:

<select
  ...
  onChange={field.handleDropdownChange}
>
  <option value="2">February</option>
</select>

I am positive that the 2nd event is triggering the onChange, because I am certain that handleDropdownChange is being called again.