Closed
Bug 1181461
Opened 9 years ago
Closed 9 years ago
onblur event should be fired upon node removal
Categories
(Core :: DOM: Events, defect)
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
Updated•9 years ago
|
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.
Description
•