User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 When reading the value of document.activeElement inside a function called from onblur="", then value is always [body], even if another element is receiving focus (as would happen when a user is tabbing through sequential form fields). This might be related to Bug 343642, but is occurring in a normal web page, rather than in background tabs, so I'm reporting it anyway. Reproducible: Always Steps to Reproduce: 1. Generate a web page with at least 2 form fields. 2. Attach a function to onblur that records the value of document.activeElement (don't use an alert, since this changes focus, instead write to a div or use firebug to set a breakpoint). 3. Set focus on the first field, and then tab or click to the next. Actual Results: document.activeElement returns [body] as having the focus. Expected Results: document.activeElement should be returning the field or page element that is receiving focus, and only return [body] if no other element applies.

This demonstrates the issue described. The value in document.activeElement is correct for the focus event, but is not correct for blur when focus is shifting to another field. The standards documentation for document.activeElement is somewhat ambiguous on whether or not this behavior is actually a bug per the standard. I feel, however, that having this property always contain the element that is receiving focus would make it substantially more valuable than reverting to [body] prior to the focus event firing. This is the implementation used by Internet Explorer 7.0 and Opera 9.51.

The blur event fires after the element has already lost focus, so it would seem that if activeElement returned the element being blurred, it would actually be incorrect. Perhaps IE and Opera are firing it before focus is lost? Note that the spec at http://dev.w3.org/html5/spec/Overview.html#focus says that the blur event should occur after the element has already been unfocused. This would be fairly tricky to implement anyway.

Neil, I think that you misunderstood me. Obviously you wouldn't want the blur event to set activeElement to the element being blurred, that wouldn't be useful or unique regardless, and the specs just add another reason not to do that. What I was requesting was the blur event (or perhaps whatever default focus code runs after the blur event) set activeElement to the element scheduled to receive focus (i.e. the next in the tab order if tab was pressed, or the clicked element if the mouse was used). I figure you have to store that information someplace while the previous element is being blurred, since the transfer of focus works properly. How hard would it be to make that information available to activeElement? Thanks, Ben

It would be simple enough to provide the element to be focused as a property of the blur event. It would not be set as the activeElement though, as it would be incorrect to imply that the activeElement was a certain element that was not yet actually focused.

FWIW, I tested IE10 on Windows 7 and Chrome on OS X 10.9; - Chrome agrees with us (activeElement on blur is BODY), while - IE10 reports the element to be focused as activeElement. I honestly can't make sense of the specification at http://www.w3.org/html/wg/drafts/html/master/editing.html#focus to figure out where it says that BODY is the element that should be activeElement during the blur event, but I believe Neil.

http://www.w3.org/TR/DOM-Level-3-Events/#events-focusevent says that blur is sent after the element loses focus. The reporter actually wants was is now the 'relatedTarget' property, but we don't currently implement it. This is bug 962251.

Thanks! I noted this in https://developer.mozilla.org/en-US/docs/Web/Events/blur