miscoded

Looks like it is referenced in the HTML5 spec at http://www.whatwg.org/specs/web-apps/current-work/#focus-management and on the mailing lists at http://www.google.com/search?q=whatwg+%22document.activeElement%22

Michael

Am I missing something?

opera.addEventListener('AfterEvent.mousedown',function(ujsEv) {
  var ev = ujsEv.event,
    target = ev.target,
    cNode = target && target.selectSingleNode('ancestor-or-self::*[ ((name()="a" or name()="area") and @href) or name()="input" or name()="button" or name()="textarea"]');
  //target.setActive();
  //Method not supported
  //target.focus();
  //Works better
  opera.postError('Clickity Click:\n\tcNode='+cNode+'\n\tactiveElement='+document.activeElement+'\n\t'+((cNode==document.activeElement)?'Same':'Different'));
},false);

Doesnt seem to work very well on links (buttons and inputs seem to work ok). Uncommenting target.focus() seems to improve things, but still doesnt work properly all the time eg. the "Blog", "Links", "Friends", "About" links work with target.focus() but the link to your Facebook post doesnt

Edit: I guess the Facebook link doesnt work because of the span in the anchor element? Never the less in IE7 it work as expected

"if the active element is removed from the document, activeElement is BODY"

Try it here:
http://msdn2.microsoft.com/en-us/library/ms537505.aspx

Repeatedly run this:
javascript:void(document.activeElement.parentNode.removeChild( document.activeElement)); alert(document.activeElement?document.activeElement.tagName: document.activeElement);

Notice it seems to step up a series of divs, until it reaches the body. The divs are the offsetParents (tested on my own page). Finally, if you delete the body, it becomes null.

On my own site, that triggers standards mode (the MSDN site triggers quirksmode), deleting the body gives the HTML element. Deleting the HTML element gives null. Again, that makes sense wrt offsetParents, since the offsetParent of body is null in quirks, but since it can be rendered separately from the viewport/HTML in standards mode - as it is with my site - and that makes it the offsetParent of BODY.

So basically, the algorithm is:
If the active element is deleted from the document, the active element becomes the offsetParent of that element. If the element has no offsetParent, then the activeElement becomes null. If the element and its offsetParent are deleted at the same time:
document.activeElement.offsetParent.parentNode.removeChild( document.activeElement.offsetParent)
then the activeElement becomes the offsetParent of the element's offsetParent - basically stepping up the offsetParent chain until it finds something that still exists - or null if it steps off the end of the offsetParent chain.

I see that Opera also returns an input element if you have merely pre-focused it with spatial navigation. Is that correct? I guess not but perhaps you guys found use cases for it.

Anyhow, it breaks a little keyboard navigation user script I'm making. How can we detect pre-focus as opposed to real focus in Opera?

The script is a user script that uses a hotkey to enumerate all links on the page for quick keyboard access (see FF's mouseless browsing extension). I use the hotkey L. Using activeElement to check if current focus is in a form field (you don't want the feature to trigger whenever typing an L in a form field) I notice I can't start the script when prefocus happens to linger on a form field. However one can still use Opera's single-key shortcuts when prefocus is around a form field, the shortcuts go to the page not the form.

Per definition, an "active" element is the one that takes input. As prefocused elements don't I guess prefocus shouldn't influence activeElement.