Given a web page with input fields, does it have a performance difference whether or not you assign the onblur handler inside of the onfocus handler like so:
var inputFields = document.querySelectorAll("input");
for (i = 0; i < inputFields.length; ++i) {
var thisInput = inputFields[i];
thisInput.onfocus = function(){
console.log("input received focus");
this.onblur = function(){
console.log("input lost focus");
thisInput.onblur = null;
}//end onblur handler
}//end onfocus handler
}//end for loop
My thought was that this would only add the blur event when the input event received focus and that the blur handler could be removed when the blur processing was done. I thought perhaps this would improve efficiency since there are less event handlers attached at a given time versus assigning all input fields the onblur handler at setup. Are there any caveats to setting up the code this way? If it matters, this will be used in a firefox extension.
4
The performance difference will be negligible. Technically the focus handler is doing extra work by attaching an event handler to the element, so performance should slow down, however I doubt this is a measurable difference.
If the number of event handlers is slowing the page down, JavaScript Event Delegation is a better response to the performance problems.
Focus and blur events are little tricky for event delegation. Newer browsers support the “focusin” and “focusout” events, which are bubbling versions of “focus” and “blur” respectively:
document.documentElement.addEventListener("focusin", handleFocus, false);
document.documentElement.addEventListener("focusout", handleFocus, false);
Older browsers only support “focus” and “blur” which do not bubble. You can still support those older browsers if they properly support addEventListener by attaching the handlers to the capturing phase of an event:
document.documentElement.addEventListener("focus", handleFocus, true);
document.documentElement.addEventListener("blur", handleBlur, true);
This means you attach 1 event handler per event at page load. The document.documentElement property references the <html> element, and is available the moment JavaScript begins executing, so no more waiting for the DOM to be “ready”.
Then you just need to detect if the target of the event is an element you care about before doing work:
function handleFocus(event) {
if (event.target.nodeName !== "INPUT") {
return;
}
console.log("input received focus");
}
function handleBlur(event) {
if (event.target.nodeName !== "INPUT") {
return;
}
console.log("input lost focus");
}
So really, you are likely trying to solve the wrong performance problem.
The benefit you gain by attaching the “blur” event handler on focus is you do less work at page load to attach event handlers. You can mitigate this problem by utilizing event delegation instead.
And there is one more benefit to event delegation that isn’t obvious. When dynamically adding elements to the page, either by calling appendChild(element) or parsing HTML via element.innerHTML = "..." you don’t need to do any additional work to attach event handlers to the newly added<input> elements. It really helps clean up and simplify your event handler code.
does it have a performance difference.
I thought perhaps this would improve efficiency since there are less event handlers attached at a given time versus assigning all input fields the onblur handler at setup
No it won’t. Having lots of attached events that never actually gets called won’t make handling of other events slower.
Having attached events may increase memory usage, but unless you’re attaching to thousands of elements, the increase in memory usage is usually negligible. If you do need to do attach to thousands of elements for some reason, do consider using event delegation instead.
Focus always fires blur and blur always fires focus, so you cannot separate them in any way. In addition, native mouse and keyboard events are asynchronous, so they cannot block like a custom event created programmatically via dispatchEvent:
Unlike “native” events, which are fired by the DOM and invoke event handlers asynchronously via the event loop, dispatchEvent invokes event handlers synchronously. All applicable event handlers will execute and return before the code continues on after the call to dispatchEvent.
Here is the logic:
focusing on a focusable element fires a focus event at the element
focusing on a focusable element fires a blur event at the previous focused element
The document received focus by default, so this is always the case. Use the W3C tests for reference:
<script>
var i1 = document.getElementById('i1'),
i2 = document.getElementById('i2'),
t1 = async_test("focusing on a focusable element fires a focus event at the element"),
t2 = async_test("focusing on a focusable element fires a blur event at the previous focussed element");
i2.onfocus = t1.step_func_done(function(e){
assert_true(e.isTrusted, "focus event is trusted");
assert_false(e.bubbles, "focus event doesn't bubble");
assert_false(e.cancelable, "focus event is not cancelable");
assert_equals(document.activeElement, i2);
});
i1.onblur = t2.step_func_done(function(e){
assert_true(e.isTrusted, "blur event is trusted");
assert_false(e.bubbles, "blur event doesn't bubble");
assert_false(e.cancelable, "blur event is not cancelable");
});
i1.focus();
i2.focus();
</script>
The User Timing API can be used to test performance.
References
-
Web Platform Tests: Focus Management
-
Accurately measuring layout on the web | Read the Tea Leaves
-
EventTarget.dispatchEvent() – Web APIs | MDN
1