jsFiddle: http://jsfiddle.net/KQBfP/3/

Does the same problem occur if the example is coded in pure DOM functions? If so we probably can't fix it.

The problem does seem to occur in pure DOM functions i.e.

<div onmousedown="return false;"></div>

However, I have found a workaround. It appears that the document.activeElement doesn't actually get set by IE until a later stage - so I store it and make a timeout that refocuses it after the mousedown has been handled: http://jsfiddle.net/KQBfP/5/

Can this workaround be intergrated into jQuery? If so, I think the only extra work needed would be to integrate this technique with jQuery's existing event handlers. Basically, all event handlers would have to wait for the originally focused element to be refocused before executing - in case they reference document.activeElement themselves.

Also, the .focus() call in refocus() (see the jsFiddle) would not have to trigger any .focus() event handlers itself.

Of course, all of this is IE<=8 conditional.

Thanks for doing some research on this. Can you verify that the jQuery(edge) build fixes this problem? If so, it should work fine in 1.7.

http://jsfiddle.net/KQBfP/9/

No worries. jQuery(edge) doesn't appear to fix the issue; clicking on div3 can still steal focus from div1 or div2.

I agree, 1.7b1 doesn't fix the problem but since it breaks for bare DOM that isn't too surprising.

However, I have found a workaround. It appears that the document.activeElement doesn't actually get set by IE until a later stage - so I store it and make a timeout that refocuses it after the mousedown has been handled

It is very risky to incorporate fixes into core that involve asynchronous actions, since they can cause problems if subsequent (immediate) events would override that delayed action.

I tried looking at special IE events like onbeforeactivate but they don't leave the focus in the right place:

http://msdn.microsoft.com/en-us/library/ms536791%28v=vs.85%29.aspx

This is a pretty obscure edge case so I am going to close it. If there is a way to fix it that doesn't involve asynchronous actions I'd consider it though.

This bug is currently blocking a fix in jQueryUi for Autocomplete. See https://github.com/scottgonzalez/jquery-ui/compare/autocomplete-syncchange. It is mentioned on the net here: http://stackoverflow.com/questions/6677082/ie-event-propagation-problem-jquery-autocomplete-jscrollpane

and also appears to be the cause of this old bug and other similar bugs:

http://bugs.jquery.com/ticket/4029

So, its not that obscure of an edge case. For lots of current and future jQueryUI stuff, its pretty important to be able to keep a mousedown from causing a blur event.

Replying to [comment:7 spekary]:

This bug is currently blocking a fix in jQueryUi for Autocomplete.

I don't think that's true. A bug in IE is blocking the fix for autocomplete. IE treats focus/blur asynchronously anyway, so there's nothing jQuery can do to fix the problem.

This is 3 years late but I just discovered there is in fact a way to get IE ≤ 8 to do what e.preventDefault() on mousedown does in other browsers (which prevents selection **and** prevents focus): set the unselectable attribute! http://stackoverflow.com/a/17525223/362030

Note that unlike the workarounds always suggested (including comment:3), which always boil down to setTimeout(function() { thingIDidntWantFocusStolenFrom.focus(); }), this prevents focus from ever being stolen by the mousedown target in the first place!

What's funny about unselectable is that it isn't inherited, so it's often overlooked in favor of the selectstart event (which bubbles, and e.preventDefault() on which prevents selection but **doesn't** prevent focus), or set on every descendant element with a tree-traversal, but you can actually just set it on event.target on mousedown: http://jsbin.com/yagekiji/1

Unfortunately I can't think of a way to work this into a clean jQuery patch that avoids asynchronous actions, because setting unselectable is a permanent side-effect. The main problem, permanency, that just because e.preventDefault() was called on **this** mousedown doesn't mean we want selection and focus prevented forever, should be completely solved by listening for the next mousedown and, before running any user-supplied handlers, resetting (unsetting) unselectable (it only blocks selections starting in that element, which must fire mousedown on that element first). The minor problem, that it's a side-effect and the user could theoretically check for unselectable on the DOM element, is kind of well you're peeking at exactly the stuff you asked us to hide from you, what did you expect, but could be mitigated by resetting (unsetting) unselectable in a timeout after the mousedown.

In any case, I think this is an ingenious workaround for the common use case of "I don't want clicking anywhere in this element to steal focus from anywhere, ever"!