'change' event not triggering after some action in 'input' event handler
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | verified |
People
(Reporter: vladsoshin2016, Assigned: emilio)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
- Open the attached file in Firefox 67.0 (64-bit)
- Open the JavaScript Console
- Select the 'Valid value 1' item in the dropdown
- Then select the 'Valid value 2'
- Then select the 'Valid value 3'
- Then select the 'Valid value 2' again
- Then return the selection to the 'Not valid value'
Actual results:
The next messages appeared in the console:
Change to: Valid value 2
Change to: Valid value 1
Expected results:
The script print current value to console after every value change:
Change to: Valid value 1
Change to: Valid value 2
Change to: Valid value 1
Change to: Not valid value
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
I guess the root cause came from CSS content property if I remove it or change to other property the symptom is gone. I got a TypeError: this.element is null when I select from Not valid value to Valid value 2 or from Valid value 2 to Not valid valid. The error came from SelectChild.jsm. Hence, I change to Layout component.
|
||
Comment 2•5 years ago
|
||
The priority flag is not set for this bug.
:mats, could you have a look please?
For more information, please visit auto_nag documentation.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 3•5 years ago
|
||
Sorry, had missed comment 2.
In general it looks like we dispatch both "input" and "change" sync, but the input reframing uninitializes the select() and nulls it out.
Should be straight-forward to fix. We need to make that code look more like:
let element = this.element; // Running arbitrary script below which can close us.
let inputEvent = new win.Event("input", {
bubbles: true,
});
element.dispatchEvent(inputEvent);
let changeEvent = new win.Event("change", {
bubbles: true,
});
element.dispatchEvent(changeEvent);
|
|
Assignee | |
Comment 4•5 years ago
|
||
Here's a reduced test-case:
<!doctype html>
<select>
<option>a</option>
<option>b</option>
</select>
<script>
let select = document.querySelector("select");
select.addEventListener("input", function() {
console.log("input");
this.style.display = "none";
this.getBoundingClientRect();
})
select.addEventListener("change", function() {
console.log("change");
})
</script>
|
|
Assignee | |
Comment 5•5 years ago
|
||
I don't know how many automated tests for <select> interactions we have, but
see https://bugzilla.mozilla.org/show_bug.cgi?id=1561882#c4 for a test-case
that I'm happy to convert to automated if you tell me where to cargo-cult from :)
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/32344abf0490 Make sure to dispatch input and change consistently even if the first causes us to get uninited. r=mconley,Gijs
|
||
Comment 7•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
||
Comment 8•5 years ago
|
||
Following the STR from the first comment, I managed to reproduce the issue on beta 67.0.
I can confirm that the issue is fixed in 70.0b6.
Description
•