New issue
Advanced search Search tips

Issue 866242 link

Starred by 1 user
Status: WontFix
Owner:
tkent@chromium.org
Closed: Jul 24
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Input OnChange fires when input is removed from DOM - potential memory leak

Reported by jimmy.th...@gmail.com, Jul 21 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. Go to http://jsfiddle.net/Jemt/4tgnj8ds/1 in any browser
2. Enter "ABC" in the input field and press ESC to remove the input from DOM

What is the expected behavior?
OnChange should not fire which is the case for Edge, Firefox, and Safari

What went wrong?
OnChange fires in Chrome - the handler should have been disposed.
Doesn't work as expected with Chrome 59 or 45 on Windows either (didn't test versions in between, only the specific versions).

Did this work before? No 

Chrome version: 67.0.3396.99  Channel: stable
OS Version: OS X 10.11.6
Flash Version: 

We have dialogs that closes when the users presses ESC. When a dialog is closed all objects (including input fields) are disposed - but the OnChange handler fires, even though one would expect it to be disposed when not keeping any references to it.

There could be a potential memory leak here if event handlers and their scope is not disposed.

If this doesn't work as expected, we probably can't trust the garbage collector, and should therefore detach all handlers from any object removed from DOM. Reminds me of all the trouble we went through with IE ten years ago.

Comment 1 by jimmy.th...@gmail.com, Jul 21 

Does NOT work as expected for textarea:
http://jsfiddle.net/Jemt/btwp8Lnu/

Does NOT work as expected for Button (e.g. OnBlur fires when removed):
http://jsfiddle.net/Jemt/6womzgsk/

Works as expected for a drop down control:
http://jsfiddle.net/Jemt/3wsvbr4j/1/
 - Probably because it fires OnChange immediately when value is changed rather than after focus is lost.

As the second example demonstrates this is not isolated to OnChange events, although the problem could originate from the code that handles OnBlur since OnChange is fired when a control loses focus.

Comment 2 by krajshree@chromium.org, Jul 22

Labels: Needs-Triage-M67

Comment 3 by dtapu...@chromium.org, Jul 23

Components: -Blink Blink>Forms

Comment 4 by tkent@chromium.org, Jul 24

Components: Blink>HTML>Focus
Labels: -Via-Wizard-Javascript -Needs-Triage-M67 Hotlist-Interop
Owner: tkent@chromium.org
Status: WontFix (was: Unconfirmed)
This behavior was inherited from WebKit, however it seems WebKit changed the behavior after Blink fork.

The current behavior matches to the HTML standard.

https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule
>  When the designated focused area of the document is removed from that Document in some way (...), designate the Document's viewport to be the new focused area of the document.

https://html.spec.whatwg.org/multipage/interaction.html#unfocusing-steps
> When the currently focused area of a top-level browsing context is somehow unfocused without another element being explicitly focused in its stead, the user agent must immediately run the unfocusing steps for that object.

So we should "unfocusing steps", "focusing steps", and "focus update steps", which dispatches 'change' and 'blur' events.

We change the behavior if the specification is changed.  So please file an issue on https://github.com/whatwg/html/issues .

Comment 5 by jimmy.th...@gmail.com, Jul 24 

I have requested clarification in the spec:
https://github.com/whatwg/html/issues/3847
►

Sign in to add a comment