The focusin event fires after focus when an element receives focus—and unlike focus, it bubbles. Learn onfocusin, form delegation, relatedTarget, the focusout pair, and five try-it labs.
01
Kind
Instance event
02
Type
FocusEvent
03
Bubbles?
Yes
04
Handler
onfocusin
05
Pair
focusout
06
Status
Limited availability
Fundamentals
Introduction
focus is perfect when you attach a listener directly to one control. When you want one listener on a form or dialog to react to every child that gains focus, focusin is the event designed for that job because it bubbles.
It fires after focus. Its opposite is focusout (which bubbles after blur). MDN marks focusin as Limited availability (not Baseline)—still widely useful, but always verify support for your audience.
💡
Beginner tip
If a parent focus listener never runs for child inputs, that is expected—focus does not bubble. Switch to focusin (or listen for focus in the capture phase).
Concept
Understanding focusin
An instance event that answers: “Did this element (or a descendant) just receive focus?” when you listen on an ancestor.
Fires after focus when an element receives focus.
Bubbles — ideal for event delegation on forms and containers.
Not cancelable — preventDefault() does not block focusing.
FocusEvent — relatedTarget is the element losing focus (if any).
Handler — onfocusin or addEventListener("focusin", ...).
Limited availability on MDN (not Baseline)—test carefully.
Foundation
📝 Syntax
Use the event name with addEventListener, or set the handler property:
The element receiving focus (often a child of your listener)
currentTarget
The element you attached the listener to (e.g. the form)
relatedTarget
The element losing focus, if any (may be null)
bubbles
true for focusin
cancelable
false — not cancelable
Sequence
🔁 Event Order (A → B)
When focus moves from element A to element B, browsers typically dispatch:
blur on A
focusout on A (bubbles)
focus on B
focusin on B (bubbles)
MDN notes that the UI Events specification describes an order that can differ from what current browsers implement—write code that does not depend on fragile interleaving details beyond this common pattern.
Compare
⚖️ focusin vs focus
Topic
focus
focusin
When
Element receives focus
Same moment, after focus
Bubbles?
No
Yes
Best for
Listener on the element itself
Delegation on a parent
Opposite pair
blur
focusout
MDN status
Baseline Widely available
Limited availability (not Baseline)
🔔
Fallback idea
If you must support environments where focusin is awkward, you can still delegate with addEventListener("focus", handler, true) (capture phase). Prefer focusin when it is available and clearer.
focusin is marked Limited availability on MDN (not Baseline). Logos use the shared browser-image-sprite.png sprite from this project. It is widely used for form delegation—still verify support for your audience, and keep capture-phase focus as a mental fallback.
✓ Limited availability
Element focusin
Bubbling focus signal for parent listeners; confirm support in your target browsers.
LimitedNot Baseline
Google ChromeSupported (check BCD for edge cases)
Supported
Mozilla FirefoxSupported in modern versions
Supported
Apple SafariSupported in modern versions
Supported
Microsoft EdgeSupported · Chromium
Supported
OperaSupported · Modern versions
Supported
Internet ExplorerLegacy support existed; prefer modern browsers
Legacy
focusinLimited
Bottom line: Prefer focusin for form delegation when available; pair with focusout and test carefully.
Wrap Up
Conclusion
focusin is the bubbling “received focus” signal that follows focus. Use it for form-wide listeners, pair it with focusout, and remember MDN lists it as Limited availability.
Prefer addEventListener("focusin", ...) on parents for delegation
Clear styles / hints with focusout
Filter event.target when you only care about inputs
Null-check event.relatedTarget
Test browsers you support (Limited availability)
❌ Don’t
Expect bubble-phase focus on a form to see child fields
Rely on preventDefault() to block focusing
Leave focus styles stuck after focusout
Assume Baseline Widely available status
Overwrite onfocusin if you need multiple listeners
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about focusin
After focus—bubbles; ideal for form delegation with focusout.
5
Core concepts
💡01
After focus
received focus
Trigger
📄02
FocusEvent
relatedTarget
API
📤03
Bubbles
unlike focus
Key
⇄04
Pair focusout
clean up styles
Pattern
🎯05
Limited avail.
not Baseline
Status
❓ Frequently Asked Questions
It fires when an element has received focus, after the focus event. Unlike focus, focusin bubbles, so you can listen on a parent and still hear when child controls gain focus.
No. MDN does not mark it Deprecated, Experimental, or Non-standard. It has Limited availability (not Baseline), so always test the browsers you care about.
Both fire when an element receives focus. focus does not bubble; focusin does, and it fires after focus. For form-wide listeners, focusin is usually the simpler choice.
A FocusEvent (inherits from UIEvent and Event). relatedTarget is the element losing focus, if any.
No. The focusin event is not cancelable.
focusout — it fires when the element loses focus (after blur) and also bubbles.
Did you know?
MDN’s live example listens for both focusin and focusout on a single <form>. That one pair of listeners styles every text and password field inside—no per-input wiring required.