View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019098 | MMW 5 | General | public | 2022-05-21 07:37 | 2022-09-14 14:33 |
| Reporter | zvezdan | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 5.0 | ||||
| Target Version | 5.2 | Fixed in Version | 5.0.4 | ||
| Summary | 0019098: Input event of edit or editable dropdown should not fire change event | ||||
| Description | Here is why: A) working fine: 1. select large number of files; 2. open Auto-organize; 3. select any item from the Destination dropdown -> OK button is disabled for a few seconds; 4. wait until OK button is enabled again; 5a. give focus to other window (make sure that Auto-organize is visible) -> OK button is still enabled; or 5b. click on Destination label or any other non-active part of dialog -> OK button is still enabled; 6. repeat 3-5 with any other item from the dropdown -> OK button is always enabled when giving focus to other window; B) working wrong: 1. select large number of files; 2. open Auto-organize; 3. edit text in the Destination dropdown -> OK button is disabled for a few seconds; 4. wait until OK button is enabled again; 5a. give focus to other window (make sure that Auto-organize is visible) -> OK button is disabled for a few seconds; or 5b. click on Destination label or any other non-active part of dialog -> OK button is disabled for a few seconds. You see, your own Auto-organize is working twice to refresh the list, when text in the edit box is changed and when it loosed focus. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I would rather say that the bug is that another the 'change' event is fired on losing the focus. Firing 'change' event on input is fine -- otherwise e.g. search bar wouldn't work etc. Whenever the input text is changed then it is expected to fire the 'change' event. |
|
|
Firing change on loosing focus is default intended behavior. Here is the excerpt from the web (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/input_event): "The input event is fired every time the value of the element changes. This is unlike the change event, which only fires when the value is committed, such as by pressing the enter key, selecting a value from a list of options, and the like." |
|
|
I already resolved that problem in my add-on by checking in the change event handler if the current value is the same is the previous one. But it is a hack. The right approach would be to listen on both input and change events. |
|
|
Hmm, based on https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/input_event https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event you seem to be right that differentiate 'change' and 'input' would be more correct here, there is just a risk of regressions for all the places where only 'change' event is listened atm. Plus mostly the "not so wanted" need to listen both 'input' and 'change' events -- which is not a need atm. |
|
|
You are right that there would be a risk of regressions and all such controls should be tested. The simple edit box (not a part of the editable dropdown) doesn't need listening on the 'change' event, you could safely replace all such listeners with the 'input' event. The 'change' event handler is needed only to register when user clicked on the item from the list of dropdown control because the 'input' event is not fired in such case. |
|
|
Well, I just tested and I was wrong. The 'change' event is needed even for edit boxes because the 'input' event is not fired when the control has changed its content by script, but only when user type the text. |
