Closed Bug 1181461 Opened 9 years ago Closed 9 years ago

onblur event should be fired upon node removal

Categories

(Core :: DOM: Events, defect)

38 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 570835

People

(Reporter: fab, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150525141253 Steps to reproduce: 1. Visit http://jsfiddle.net/7y12z7a3/3/ (code snippet below). 2. Focus on the first input field, then press tab. <body> <div>Field 1: <input id="first" type="text"/></div> <div>Field 2: <input id="other" type="text" onBlur="alert('onblur')"/></div> </body> function kill_other(self) { var other = document.getElementById('other'); if (true) { var tmp = other.outerHTML; other.outerHTML = tmp; } else { other.parentNode.removeChild(other); } } document.getElementById('first').onblur = function () { setTimeout(kill_other, 0) }; Actual results: Nothing. Expected results: When the focus is passed from the first to the 2nd field, the "onblur" on the first field will trigger JS that will cause the second field to be removed. It should cause the "onblur" of the second field to be triggered, according to this (closed) bug in Chromium: https://code.google.com/p/chromium/issues/detail?id=439484 The bug opened for Chromium asked the opposite question: "why is onblur called". Here is the interpretation from the Chromium dev: === 8< === cut here === 8< === I think it's not a bug. The specification looks to define this, and the behavior is very logical. https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule-three > When the currently focused area of a top-level browsing context was a focusable area but stops being a focusable area, or ... > 7. Run the focus update steps with old chain, new chain, and new focus target respectively. https://html.spec.whatwg.org/multipage/interaction.html#focus-update-steps > 4. If blur event target is not null, fire a focus event named blur at blur event target, with related blur target as the related target. === 8< === cut here === 8< ===
Note that Internet Explorer 10 behaves like Firefox. Opera (Blink) and Midori (Webkit) both behave like Chrome.
Component: Untriaged → DOM: Events
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.