Bug 135552 – change event not firing on blur

• Status: NEW
• Component: DOM

[Shannon]

1. Focus on a text input field.
2. Switch to a different application.

Result: Firefox fires a blur and a change event. Webkit only fires a blur event.

This might not be so bad, since when you switch back to Webkit the field has focus again, and tabbing out will fire the change event. However, there are situations where the switch to another application needs to know the field changed.

For example, if the field has an onchange handler that causes the data to be submitted to a database, and the other application needs that data, the other application will not see the data, even though its right there on the screen and the user sees it as entered.

The example in the fiddle is a case where an onchange handler could even cause a form submit when the webkit browser is not the front application. In the example, it happens when a file upload button has a file dragged and dropped on it. In this situation, the change event never fires, even though the field changed and the form was submitted.

Recommendation: If a blur happens on a changed field, the change event should fire at that time, and not be delayed.

[Lucas Forschler]

Mass move bugs into the DOM component.

[Ahmad Saleem]

I am able to reproduce this bug in Safari 15.6 on macOS 12.5 from attached JSFiddle, opening it and following extension, I don't get "onchange" event dialog and it navigates me to 404 error page, while in case of other browsers (Chrome Canary 106 and Firefox Nightly 105), I get 'onchange' event as soon as I switches to "Finder". Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/98526540>

[Jeff Johnson]

This bug should be renamed to something like "onchange event not firing on blur".

The bug occurs for both <input> and <textarea> elements, and you can reproduce it by clicking in the Safari address bar (or command-l), or clicking in the Safari web inspector, not just by switching applications.

This is contrary to the behavior of Chrome and Firefox. It's also contrary to the MDN web docs: "When the element loses focus after its value was changed: for elements where the user's interaction is typing rather than selection, such as a <textarea> or the text, search, url, tel, email, or password types of the <input> element."

https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event

This bug also affects Safari extension popups: when you close the popup, the change event is not fired for changed inputs and textareas, unlike in Chrome and Firefox extension popups.

[Karl Dubost]

https://html.spec.whatwg.org/multipage/input.html#common-input-element-events:event-change

> The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any).

about losing focus
https://html.spec.whatwg.org/multipage/interaction.html#unfocus-causes-change-event

> 1. If entry is an input element, and the change event applies to the element, and the element does not have a defined activation behavior, and the user has changed the element's value or its list of selected files while the control was focused without committing that change (such that it is different to what it was when the control was first focused), then fire an event named change at the element, with the bubbles attribute initialized to true.

[Ahmad Saleem]

(In reply to Karl Dubost from comment #5)
> https://html.spec.whatwg.org/multipage/input.html#common-input-element-
> events:event-change
> 
> > The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any).
> 
> about losing focus
> https://html.spec.whatwg.org/multipage/interaction.html#unfocus-causes-
> change-event
> 
> > 1. If entry is an input element, and the change event applies to the element, and the element does not have a defined activation behavior, and the user has changed the element's value or its list of selected files while the control was focused without committing that change (such that it is different to what it was when the control was first focused), then fire an event named change at the element, with the bubbles attribute initialized to true.

Is this blink commit will fix this for input text field? https://src.chromium.org/viewvc/blink?view=revision&revision=170511

[Ahmad Saleem]

(In reply to Ahmad Saleem from comment #6)
> (In reply to Karl Dubost from comment #5)
> > https://html.spec.whatwg.org/multipage/input.html#common-input-element-
> > events:event-change
> > 
> > > The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any).
> > 
> > about losing focus
> > https://html.spec.whatwg.org/multipage/interaction.html#unfocus-causes-
> > change-event
> > 
> > > 1. If entry is an input element, and the change event applies to the element, and the element does not have a defined activation behavior, and the user has changed the element's value or its list of selected files while the control was focused without committing that change (such that it is different to what it was when the control was first focused), then fire an event named change at the element, with the bubbles attribute initialized to true.
> 
> Is this blink commit will fix this for input text field?
> https://src.chromium.org/viewvc/blink?view=revision&revision=170511

Webkit GitHub Code - https://github.com/WebKit/WebKit/blob/fe8689f79ea0d1c46c2bda3b805bb4315385cf02/Source/WebCore/page/FocusController.cpp#LL310

[Alexsander Borges Damaceno]

Pull request: https://github.com/WebKit/WebKit/pull/30471