337631 - Support document.activeElement and document.hasFocus (IE's focus model)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

[Jesse Ruderman]

document.currentFocus would be very useful for bookmarklets, and it would make focus-tracking less necessary for web apps.  See http://www.squarefree.com/2006/05/06/finding-the-textarea-selection/.

Draft spec: http://whatwg.org/specs/web-apps/current-work/#the-documentfocus

Comment 1

[Asaf Romano (gone)]

Is this the same as IE's/Opera's document.activeElement?

Comment 2

[Peter Kasting]

See also bug 296469, bug 296471.

Comment 3

[Hixie (not reading bugmail)]

Yeah, please disregard "currentFocus" and assume IE's document.activeElement and its related APIs (like hasFocus) are the way to go.

Comment 4

[Peter Kasting]

Attachment: Testcases

Taking, I'm working on this and have something semi-functional.

Attachment is a .tgz of some testcases that can be used to verify proper behavior.

Comment 5

[Peter Kasting]

Attachment: patch v1

This patch seems to do what I want.

This patch contains the patch for bug 296469 (slightly modified) as well, because both touch the same files, are small, have related functionality (though no dependence on each other), and both need the uuid for nsIDOMNSDocument changed.

Accordingly, I'm asking the same people for review.

After some discussion with Hixie about the desired behavior here, this patch implements the following:
* document.activeElement will return the focused element, regardless of whether the application is focused (like IE)
* If the focused element is inside a child document, the appropriate IFRAME from this document is returned (like IE)
* If the focused element is not inside this document or a child, the BODY is returned (like IE)
* If there is no BODY (non-HTML documents, or documents where the BODY has been removed), the root element is returned (IE does not have this case)
* These behaviors are all the same regardless of whether the document is completely loaded (IE supposedly returns null until the document has loaded, presumably even if there's an active element)

Things to pay attention to in review:
* Changed patch from bug 296469 to use GetWindow(), not sure whether this is more correct
* Possibly stupid/inefficient uses of do_QueryInterface(), swap(), etc. when faster/easier methods exist
* Corner cases I forgot, security holes due to calling GetFrameElementInternal(), etc.

Comment 6

[Jesse Ruderman]

> If the focused element is inside a child document, the appropriate IFRAME
> from this document is returned (like IE)

Please make sure this works correctly <frame>, <iframe>, and <object type="image/svg+xml">.

Comment 7

[Peter Kasting]

(In reply to comment #6)
> Please make sure this works correctly <frame>, <iframe>, and <object
> type="image/svg+xml">.

If you (or someone else) could whip up a testcase or two (possibly using the existing ones on this bug as a basis), I'd be very grateful and would happily test against my patch and IE 6 to make sure I'm doing the right thing.  I only ask because my web skills are nonexistent and I have no idea what "works correctly" necessarily means :).

Comment 8

[Asaf Romano (gone)]

Comment on attachment 224280 [details] [diff] [review]
patch v1

>+NS_IMETHODIMP
>+nsDocument::GetActiveElement(nsIDOMElement **_retval)
>+{
...
>+  // No focused element anywhere in this document.  Try to get the BODY.
>+  nsCOMPtr<nsIDOMHTMLDocument> htmlDoc = do_QueryInterface(NS_STATIC_CAST(nsIDocument*, this));
>+  if (htmlDoc) {
>+    nsCOMPtr<nsIDOMHTMLElement> bodyHTMLElement;
>+    htmlDoc->GetBody(getter_AddRefs(bodyHTMLElement));
>+    nsCOMPtr<nsIDOMElement> bodyElement = do_QueryInterface(bodyHTMLElement);
>+    if (bodyElement)
>+      bodyElement.swap(*_retval);
>+  }
>+
>+  // If we couldn't get a BODY, return the root element.
>+  return (*_retval) ? NS_OK : GetDocumentElement(_retval);
>+}
>+


Wouldn't this return the <html:body>/root element for background tabs? Also note the "focusedElement" property in the tabbrowser bindings (Wondering how does IE7 handle this).

Comment 9

[Jesse Ruderman]

Attachment: Larger set of testcases

Comment 10

[Jesse Ruderman]

On the trunk, you can load the testcases in the new attachment without downloading the zip manually:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=224423!/active/

Comment 11

[Peter Kasting]

Jesse: thanks very much for the testcases, I'll look into them.

Asaf: as opposed to returning what, null?  Yes, I think this returns BODY.  I think that's also correct.  I haven't actually tried to write a testcase to figure out what happens, but it seems like background tabs should act just like non-focused windows, and those definitely return BODY (or root), and should.  I'll look at what the tabbrowser focusedElement property does, I haven't checked that out yet.  I suspect it doesn't behave like this property should behave... might just be a hook to the focuscontroller's focused element directly.

Comment 12

[Jesse Ruderman]

Is it ok that web pages will continue to have access to the focus controller's focusedElement, in addition to this new activeElement, even though the two aren't the same?  (Maybe bug 180771 is a better place to ask that question.)

Please avoid duplicating the known security holes and abstraction leaks that focusedElement has, such as bug 313566, bug 313573, and bug 313664.

Comment 13

[Peter Kasting]

So, after some testing with Jesse's testcases, some notes:

* If the user selects an IFRAME itself instead of an element in it, IE shows the IFRAME as selected, my patch shows BODY (i.e. nothing).  I think IE's behavior is correct, so I should fix this.  This probably means that if there isn't a focusedElement on the focusController, I need to look at the focusedWindow.  Maybe I can leverage some of the hasFocus() code.
* If the user selects something in chrome, IE's behavior is screwy: when mouse-clicking on the URL bar, the reported activeElement in the page doesn't change, but when tabbing to the URL bar, the activeElement changes to "none" (not even the BODY).  My patch just reports BODY in both cases.  It might be better to "remember" the activeElement on the page (like IE does in the mouse navigation case) and report that, but I'm not sure, nor do I know if that's feasible.
* I'm not sure what the script in the FRAMESET is reporting with my patch.  IE helpfully sticks some text in the status bar telling me "FRAME in FRAMESET", but I see no such stuff in Firefox.  I'll need to hack that testcase some to see what's happening and whether my patch is also reporting FRAME in FRAMESET.
* I can't test the SVG case in IE, but aside from my first comment above, I think it's doing the right thing.  Strangely, I can't tab to the OBJECT, even though I can click on it, drag away to prevent it navigating, and then use shift-tab and tab to go between the blue circle and its surrounding square... I don't know if it's a bug or not that this thing doesn't seem to be in the normal tab order.

(In reply to comment #12)
> Is it ok that web pages will continue to have access to the focus controller's
> focusedElement, in addition to this new activeElement, even though the two
> aren't the same?  (Maybe bug 180771 is a better place to ask that question.)

I don't know?  I don't really understand what bug 180771 wants to do :(

> Please avoid duplicating the known security holes and abstraction leaks that
> focusedElement has, such as bug 313566, bug 313573, and bug 313664.

I've read through these bugs briefly.  Once again my complete ignorance of almost everything is making it hard for me to figure out what they're saying.  It seems like the problem with focusedElement is that we have to be careful not to give chrome elements to callers.  In the case of my patch, we can't give out elements that aren't children of the document, so we can't give out the parent tabbrowser's chrome elements.  Doesn't that solve things?  Or am I totally confused?  What do I need to do to make sure I'm not adding (or copying) any security holes?

Comment 14

[Peter Kasting]

I just realized I think I misunderstood comment #8 entirely.

I suspect what Asaf is trying to tell me is that when you have an active element in a tab, and you switch to another tab, the background tab now reports activeElement as BODY instead of remaining unchanged.  I don't have a testcase for that, but I bet that's what happens.  Hmmmmmm.  That's not good at all.  My reply in comment #11 is way off; the problem here is the use of a tabbrowser-level focusController instead of a browser-level one.  I need to worry about this as well.

Comment 15

[Asaf Romano (gone)]

(In reply to comment #11)

> Asaf: as opposed to returning what, null?  Yes, I think this returns BODY.  I
> think that's also correct.  I haven't actually tried to write a testcase to
> figure out what happens, but it seems like background tabs should act just like
> non-focused windows, and those definitely return BODY (or root), and should. 
> I'll look at what the tabbrowser focusedElement property does, I haven't
> checked that out yet.  I suspect it doesn't behave like this property should
> behave... might just be a hook to the focuscontroller's focused element
> directly.
> 

As opposed to returning the to-be-focused element once that tab is activated (that is the focusedElement property in the tabbrowser-tab binding)... I do realize it might be hard to implement this (prolly via nsIBrowserDOMWindow?).

Comment 16

[Peter Kasting]

Attachment: patch v2

This patch fixes the issue with not supplying IFRAME as the focused element when you focus an iframe itself (instead of an element in the iframe).  It bothers me that I have to ask for the focusedWindows and go from there instead of just having the IFRAME be a possible focusedElement itself.  What's up with that?

This does NOT solve the problem of having "BODY" as the activeElement on any background tab.  I don't believe that can be solved without some major rearchitecting of how focus works.  The only place that information is tracked right now is up in browser.xml, and it's wrong to make Gecko depend on that stuff.

This also does not address the issue, if it is an issue, with what the activeElement should be when the user clicks on chrome somewhere, like in the URL bar.  If we want to "remember" the active element in that case we will once again need the focus rearchitecting I mentioned.

Behavior-wise, this patch is probably "as good as it gets" for now.  The question is whether that's something that is good enough to check in, or whether we want to hold off on this until some unspecified future date when focus is implemented differently.

Comment 17

[Asaf Romano (gone)]

Comment on attachment 224496 [details] [diff] [review]
patch v2


>+  // No focused element anywhere in this document.  Try to get the BODY.
>+  nsCOMPtr<nsIDOMHTMLDocument> htmlDoc =
>+    do_QueryInterface(NS_STATIC_CAST(nsIDocument*, this));
>+  if (htmlDoc) {
>+    nsCOMPtr<nsIDOMHTMLElement> bodyHTMLElement;
>+    htmlDoc->GetBody(getter_AddRefs(bodyHTMLElement));
>+    nsCOMPtr<nsIDOMElement> bodyElement = do_QueryInterface(bodyHTMLElement);
>+    if (bodyElement)
>+      bodyElement.swap(*_retval);
>+  }

No need to QueryInterface here (nsIDOMHTMLElement inherits the nsIDOMElement interface), then you could assign it directly to _retval.

Comment 18

[Peter Kasting]

Attachment: patch v3

This addresses comment #17.  It looks ugly, but I can't think of another solution that doesn't use extra temporaries or add/release refs.  Reviewers can probably direct me to use some extra temporaries if they think it would help readability.

Comment 19

[Brian Ryner (not reading)]

Comment on attachment 224583 [details] [diff] [review]
patch v3

>--- dom/public/idl/core/nsIDOMNSDocument.idl	26 Apr 2006 12:42:49 -0000	1.12
>+++ dom/public/idl/core/nsIDOMNSDocument.idl	6 Jun 2006 17:42:10 -0000
>-[scriptable, uuid(170763c7-c94e-4db9-98be-e69ac3a02a41)]
>+[scriptable, uuid(d9434314-b772-49d8-af0d-54126de63430)]
> interface nsIDOMNSDocument : nsISupports

You should also change the IID of any interfaces that inherit from nsIDOMNSDocument.  Currently, I think this just means nsIDocument.

>--- content/base/src/nsDocument.cpp	31 May 2006 17:57:14 -0000	3.649
>+++ content/base/src/nsDocument.cpp	6 Jun 2006 17:42:10 -0000
>@@ -1227,22 +1229,132 @@ nsDocument::SetContentType(const nsAStri
>   NS_ASSERTION(mContentType.IsEmpty() ||
>                mContentType.Equals(NS_ConvertUTF16toUTF8(aContentType)),
>                "Do you really want to change the content-type?");
> 
>   CopyUTF16toUTF8(aContentType, mContentType);
> }
> 
> NS_IMETHODIMP
>+nsDocument::HasFocus(PRBool* result)
>+{

Implementation looks good, but a comment saying how it works would be nice.

>+NS_IMETHODIMP
>+nsDocument::GetActiveElement(nsIDOMElement **_retval)
>+{
>+  *_retval = nsnull;
>+
>+  // Get the focused element.
>+  nsPIDOMWindow* window = GetWindow();
>+  if (!window)
>+    return NS_ERROR_FAILURE;
>+
>+  nsIFocusController* focusController = window->GetRootFocusController();
>+  if (!focusController)
>+    return NS_ERROR_FAILURE;
>+
>+  nsCOMPtr<nsIDOMElement> focusedElement;
>+  focusController->GetFocusedElement(getter_AddRefs(focusedElement));
>+  nsCOMPtr<nsIContent> content = do_QueryInterface(focusedElement);
>+  if (content) {
>+    // Found a focused element.  See if it's in this document.
>+    nsIDocument* currentDoc = content->GetCurrentDoc();
>+    if (currentDoc == this) {
>+      focusedElement.swap(*_retval);
>+      return NS_OK;
>+    }
>+
>+    // Not in this document.  If it's in a child document, return the iframe in
>+    // this document that's an ancestor of the child.
>+    if (currentDoc) {
>+      if (NS_FAILED(CheckAncestryAndGetFrame(currentDoc, _retval)))
>+        return NS_ERROR_FAILURE;
>+      if (*_retval) {
>+        NS_ADDREF(*_retval);
>+        return NS_OK;
>+      }
>+    }
>+  }
>+
>+  // Couldn't find a focused element.  Check if something like an IFRAME is
>+  // focused, which will give us a focused window rather than a focused
>+  // element.
>+  nsCOMPtr<nsIDOMWindowInternal> focusedWindow;
>+  focusController->GetFocusedWindow(getter_AddRefs(focusedWindow));
>+  if (focusedWindow) {
>+    // Found a focused window.  See if it's in a child of this document.  (If
>+    // the window's document is this, then we should just fall through to
>+    // returning the BODY below).
>+    nsCOMPtr<nsIDOMDocument> domDocument;
>+    focusedWindow->GetDocument(getter_AddRefs(domDocument));
>+    nsCOMPtr<nsIDocument> document = do_QueryInterface(domDocument);
>+
>+    if (document && (document != this)) {
>+      if (NS_FAILED(CheckAncestryAndGetFrame(document, _retval)))
>+        return NS_ERROR_FAILURE;
>+      if (*_retval) {
>+        NS_ADDREF(*_retval);
>+        return NS_OK;
>+      }
>+    }
>+  }
>+
>+  // No focused element anywhere in this document.  Try to get the BODY.
>+  nsCOMPtr<nsIDOMHTMLDocument> htmlDoc =
>+    do_QueryInterface(NS_STATIC_CAST(nsIDocument*, this));
>+  if (htmlDoc) {
>+    nsCOMPtr<nsIDOMHTMLElement> bodyElement;
>+    htmlDoc->GetBody(getter_AddRefs(bodyElement));
>+    if (bodyElement)
>+      (NS_STATIC_CAST(nsCOMPtr<nsIDOMElement>, bodyElement)).swap(*_retval);
>+  }
>+
>+  // If we couldn't get a BODY, return the root element.
>+  return (*_retval) ? NS_OK : GetDocumentElement(_retval);
>+}
>+
> nsresult
> nsDocument::SetBaseURI(nsIURI* aURI)
> {
>   nsresult rv = NS_OK;
> 
>   if (aURI) {
>     rv = nsContentUtils::GetSecurityManager()->
>       CheckLoadURIWithPrincipal(NodePrincipal(), aURI,
>@@ -5032,16 +5144,43 @@ nsDocument::DoUnblockOnload()
>   if (mScriptGlobalObject) {
>     nsCOMPtr<nsILoadGroup> loadGroup = GetDocumentLoadGroup();
>     if (loadGroup) {
>       loadGroup->RemoveRequest(mOnloadBlocker, nsnull, NS_OK);
>     }
>   }
> }
> 
>+nsresult
>+nsDocument::CheckAncestryAndGetFrame(nsIDocument* document,
>+                                     nsIDOMElement **_retval) const
>+/* See if document is a child of this.  If so, set _retval to the frame
>+ * element in this document that holds currentDoc (or an ancestor).
>+ *
>+ * Note that this function returns NS_ERROR_FAILURE only in abnormal
>+ * circumstances, not every time we fail to set _retval. */

I know your personal preference for comment placement, but prevailing style for this file is to comment before the function declaration.

>+  // In a child document.  Get the appropriate frame.
>+  const nsPIDOMWindow* currentWindow = document->GetWindow();
>+  if (!currentWindow)
>+    return NS_ERROR_FAILURE;

Const pointers to XPCOM objects aren't generally a good idea... I know it works here, but I'd recommend against it just based on prevailing style.

I want to go over CheckAncestryAndGetFrame a little closer, I'll do that in a follow up comment.

Comment 20

[Brian Ryner (not reading)]

Comment on attachment 224583 [details] [diff] [review]
patch v3

>+nsresult
>+nsDocument::CheckAncestryAndGetFrame(nsIDocument* document,
>+                                     nsIDOMElement **_retval) const
>+/* See if document is a child of this.  If so, set _retval to the frame
>+ * element in this document that holds currentDoc (or an ancestor).
>+ *
>+ * Note that this function returns NS_ERROR_FAILURE only in abnormal
>+ * circumstances, not every time we fail to set _retval. */

At the very least, you should explicitly state that _retval will be unmodified if |document| isn't a child of |this|.  I think I'd rather have it initialize *_retval to null though, since it's cheap and protects you from bad callers.

>+{
>+  nsIDocument* parentDoc;
>+  for (parentDoc = document->GetParentDocument(); parentDoc != this;
>+       parentDoc = parentDoc->GetParentDocument()) {
>+    if (!parentDoc)
>+      return NS_OK;
>+
>+    document = parentDoc;
>+  }
>+
>+  // In a child document.  Get the appropriate frame.
>+  const nsPIDOMWindow* currentWindow = document->GetWindow();
>+  if (!currentWindow)
>+    return NS_ERROR_FAILURE;

I believe some documents, like those created via XMLHTTPRequest or via DOMImplementation::createDocument, really don't have a window.  It seems like this shouldn't be treated as an unexpected error.

Looks good otherwise, can you post a new patch with the changes?

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 224583 [details] [diff] [review]
patch v3

>Index: dom/public/idl/core/nsIDOMNSDocument.idl

Please add new things to the end of the interface, not in the middle.

Also, please outdent the methods?  I see no reason to line up the types like that.

>Index: content/base/src/nsDocument.cpp

Please use names like "aResult" for arguments in this code.  Also, single-line if bodies still get curly braces in this file.

>+nsDocument::HasFocus(PRBool* result)

>+  nsIFocusController* focusController = window ?
>+    window->GetRootFocusController() : nsnull;
>+  if (!focusController)
>+    return NS_ERROR_FAILURE;

Like bryner said, not having a window is not an error condition -- it just means HasFocus returns false.

>+  focusController->GetActive(&active);

Is there a reason not checking the return value here is ok?

>+nsDocument::GetActiveElement(nsIDOMElement **_retval)

>+      if (NS_FAILED(CheckAncestryAndGetFrame(currentDoc, _retval)))
>+        return NS_ERROR_FAILURE;

Why not just return the rv of CheckAncestryAndGetFrame?

>+      if (*_retval) {
>+        NS_ADDREF(*_retval);

I'd _really_ prefer that CheckAncestryAndGetFrame do this addref.  It looks  like a getter, complete with the right signature, but doesn't behave like one.  I don't really see a reason for it not to.

>+  // No focused element anywhere in this document.  Try to get the BODY.

I'm not completely sure how happy I am about doing this, but I can't think of a reasonable way to factor this code into nsHTMLDocument... so let's take it for now.

>+      (NS_STATIC_CAST(nsCOMPtr<nsIDOMElement>, bodyElement)).swap(*_retval);

Just assign-and-addref instead of swapping.  The casting there just isn't worth it for something that's not a huge perf issue.

>+nsDocument::CheckAncestryAndGetFrame(nsIDocument* document,

>+  for (parentDoc = document->GetParentDocument(); parentDoc != this;
>+       parentDoc = parentDoc->GetParentDocument()) {

This will crash if |this| is not on the parent chain of |document| (which can happen).

>+  *_retval = currentWindow->GetFrameElementInternal();

At this point we need to check that the element's owner document is |this|.  Otherwise we could indeed run into issues if the current document in |currentWindow| is not |document| or something wacky like that.

Looks pretty good in general; I'd also like to see an updated patch.

Comment 22

[timeless]

will there be some way for users to force hasFocus to always return true?

the last thing i want is web pages tossing up dialogs when hasFocus is false.

Comment 23

[Jesse Ruderman]

timeless: huh?

Comment 24

[Peter Kasting]

Attachment: patch v4

This should address the review comments, except as follows:

"You should also change the IID of any interfaces that inherit from
nsIDOMNSDocument.  Currently, I think this just means nsIDocument."

Actually, nothing inherits from nsIDOMNSDocument, so there are no changes here.

">+  for (parentDoc = document->GetParentDocument(); parentDoc != this;
>+       parentDoc = parentDoc->GetParentDocument()) {

This will crash if |this| is not on the parent chain of |document| (which can
happen)."

No, it won't crash, since I explicitly check for parentDoc == nsnull in the loop body and return.

Also, with the review comments addressed, CheckAncestryAndGetFrame() no longer needed to return an nsresult, so I had it just go ahead and return the (now AddRef'd) frame element directly, which invalidated a few review comments.

Thanks for the thorough reviews, guys.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 225490 [details] [diff] [review]
patch v4

>Index: content/base/src/nsDocument.cpp

>+nsDocument::GetActiveElement(nsIDOMElement **aElement)

>+  if (!window) {
>+    return NS_ERROR_FAILURE;

If we want to throw here, better to throw NS_ERROR_NOT_AVAILABLE.  But maybe we want to just return null?

>+  if (!focusController) {
>+    return NS_ERROR_FAILURE;

Similar (though it makes more sense to thrown here).

Looks beautiful apart from those nits.  sr=bzbarsky; no need for further review from me unless bryner asks for nontrivial changes. ;)

Comment 26

[Peter Kasting]

Attachment: patch v5

This patch makes one change in response to bzbarsky's nitpicks: if we can't get a window, we throw ERROR_NOT_AVAILABLE instead of ERROR_FAILURE.  I don't think GetActiveElement() should ever return null, so I didn't want to do that.  And bryner tells me windows should always have root focus controllers, so if we can't get one, that definitely seems like ERROR_FAILURE, since that shouldn't ever happen.

Comment 27

[Brett Wilson]

Fixed on trunk.

Comment 28

[Robert Sayre]

RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_bug337631.html,v
done
Checking in test_bug337631.html;
/cvsroot/mozilla/testing/mochitest/tests/test_bug337631.html,v  <--  test_bug337631.html
initial revision: 1.1
done

Comment 29

[chris eidhof]

Just out of curiosity, as I'm pretty new to Firefox Development: when will this actually be in a released version of Firefox? How do those things go?

Comment 30

[Shawn Wilsher :sdwilsh]

(In reply to comment #29)
> Just out of curiosity, as I'm pretty new to Firefox Development: when will this
> actually be in a released version of Firefox? How do those things go?
> 

This landed in trunk, so Firefox 3

Comment 31

[chris eidhof]

Would it be possible to backport it to a 2.x release?

Comment 32

[Peter Kasting]

(In reply to comment #31)
> Would it be possible to backport it to a 2.x release?

Doubtful.  This sort of change is the type of thing that typically waits for new Gecko revisions.  It's not a security/crash/etc. fix or a high-profile bug, it's a web dev feature request.

Implementation-wise, to be backported the fix would need to change the 1.8.1-specific interfaces so as not to break compatibility.  If you really want this you can nominate it, but I suspect that drivers will minus.

Comment 33

[robinpelgrim]

Let me note that in IE when loosing focus on an element during the onblur event the activeElement is the next focussed element and NOT the body element as in this implementation.

When tabbing to the next control the focus will never be on the body element, so how can it be returned as activeElement?

It is questionable whether the active should be the 'blurred' element or the focussed element but it's incompatible with IE...

(I'am looking for a way to find out what is the newly focusses element during the onblur event, this could have been the way...) 

Comment 34

[Peter Kasting]

(In reply to comment #33)
> Let me note that in IE when loosing focus on an element during the onblur event
> the activeElement is the next focussed element and NOT the body element as in
> this implementation.
> 
> When tabbing to the next control the focus will never be on the body element,
> so how can it be returned as activeElement?

This may simply be exposing the way the Firefox focus controller works under the hood.  If you change focus by first removing focus from one element and then setting focus on another element, then between those two operations nothing has focus.  If we fire onblur in that state, activeElement will return BODY since that's what's returned when nothing has focus.

This isn't in any spec.  If you really care about seeing it happen, I suggest opening a new bug and making the feature request there.  It may be very tricky to fix, though.