This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 19804 - relatedTarget on blur/focus should match focusout/focusin
Summary: relatedTarget on blur/focus should match focusout/focusin
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-31 21:14 UTC by Ojan Vafai
Modified: 2013-08-25 17:59 UTC (History)
3 users (show)

See Also:

Attachments

Description Ojan Vafai 2012-10-31 21:14:17 UTC 
http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0061.html

Right now relatedTarget is specced as being null on blur/focus. Why don't these just match focusout/focusin?

Doing some spec archaeology, it looks like relatedTarget was specced as having the same value as target on blur/focus and then set to null in response to http://lists.w3.org/Archives/Public/www-dom/2010JanMar/0010.html.

It seems to me that there's no downside to making relatedTarget do the same thing on focus/blur that is does on focusout/focusin respectively. From a web developers perspective, the only difference should be whether the event bubbles or not and whether it fires before/after focus has shifted.

I know this is late in the cycle, but I just noticed this and this seems reasonable to include in the level 3 version of this spec.
Comment 1 Gary Kacmarcik 2013-08-25 17:59:58 UTC 
Fixed in latest ED.

relatedTarget for blur copied from focusout
relatedTarget for focus copied from focusin

(The bug says to "do the same thing on focus/blur that is does on focusout/focusin respectively", but I think that's reversed (or else I'm not understanding something).