_onFocus is called before _onMouseDown

[siqi]

Open dijit/tests/form/test_CheckBox.html, add following code into dojo.addOnLoad:

dojo.connect(dijit.byId("cb1"), "_onMouseDown", function(){console.log("mouseDown");});
dojo.connect(dijit.byId("cb1"), "_onFocus", function(){console.log("focus");});

Click on the checkbox, it prints "focus" thand "mouseDown" in the console.

Is it what we expected? I think "_onMouseDown" should be called before "_onFocus", in the same order as the native events 'mousedown' -> 'focus' -> 'mouseup' -> 'click'.

[bill]

This is expected, due to how the focus manager is written: it catches the onmousedown event before cb1 does, and then calls cb1._onFocus(). Note that _onFocus is misnamed as it doesn't correspond exactly to DOM focus events, but too late to change the name now.

You could always connect to "onfocus" on cb1.focusNode to get the behavior you want.

[siqi]

Replying to bill:

This is expected, due to how the focus manager is written: it catches the onmousedown event before cb1 does, and then calls cb1._onFocus(). Note that _onFocus is misnamed as it doesn't correspond exactly to DOM focus events, but too late to change the name now.

You could always connect to "onfocus" on cb1.focusNode to get the behavior you want.

Oh yes, you're right. The work around works well. :-)

[bill]

OK great. We could make _onFocus() occur after _onMouseDown() with a setTimeout(), but we try to avoid setTimeout() whenever possible. Other than that I don't know a way to change the order of those events. So I'm going to mark this as wontfix for now, directing people to use that workaround.

[siqi]

Replying to bill:

OK great. We could make _onFocus() occur after _onMouseDown() with a setTimeout(), but we try to avoid setTimeout() whenever possible. Other than that I don't know a way to change the order of those events. So I'm going to mark this as wontfix for now, directing people to use that workaround.

Exactly, setTimeout() is always not what we want....:-)

[bill]

#14838 is a duplicate of this ticket.

[bill]

#15132 is a duplicate of this ticket.

[bill]

I suppose if we did have a setTimeout(), it could be to trigger the so-called _onFocus() event when there was a mousedown event which wasn't followed immediately by a focus event (such as the case of clicking the non-focusable up/down arrows on a spinner). I.e. setup a timer on mousedown, but clear it onfocus.

Perhaps since this has come up a number of times I should do that. I'll reopen this to consider.

Alternately, perhaps the focus manager should just ignore mouse events, and clicking the up/down arrows on a spinner shouldn't cause it to focus.

PS: Need to think about _onBlur() events too though. Ideally clicking the arrows on a focused spinner shouldn't cause an _onBlur() call, since that would make the value reformat from 12345 to 12,345. Or worse yet, an _onBlur() followed after 0ms by another _onFocus().

Also consider stuff like iOS where the mousedown, mouseup, and click events all occur together. We wouldn't want an _onFocus() call to occur after the click event, as it might lead to problems like an onclick listener opening a TooltipDialog and then the Button._onFocus() call immediately closing that TooltipDialog.

[Douglas Hays]

In [28290]:

Refs #14968, #13341. Move _onMouseDown processing to _onFocus(by=mouse) to better align with the focus manager's current behavior of invoking _onFocus before onfocus and before onmousedown.

[bill]

In [30957]:

Change focus manager to use dojo/on rather than addEventListener() and attachEvent() on older IE's. This makes the behavior consistent across browsers (as to listening on capture phase vs. bubbling phase), and as a side effect fixes #13341 !strict.

[bill]

In [30994]:

Fix regression from [30957]: evt.target is the normalized way to reference the event target, not evt.srcElement. Fixes exception on firefox. Refs #13341 !strict.

[bill]

In [31012]:

Need to listen for touchstart in addition to mousedown, or otherwise clicking a blank area of the screen won't close popups on iOS. Fixes regression from [30957], refs #13341 !strict. Behavior still not perfect: clicking a blank area of the screen closes the popup but then focuses the associated input (at least on test_DateTextBox.html), unwantedly bringing up the keyboard.

[bill]

In [31237]:

update test to not rely on dijit/focus, and add TODO about apparently problem with dijit/focus code, refs #13341 !strict

[Bill Keese <[email protected]…>]

In 76216d6d829f011a87ccd11ee12d3a862d6e2e88/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Bill Keese <[email protected]…>]

In d5eef52f83e77b9d501ce0309b4f4d69b64c6a04/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[bill]

[30957] backported to 1.8 in e2b992b720df9936af690e08de1a76c299f38613.

[Bill Keese <[email protected]…>]

In 809130120f849c06f71ceadc8edeb3e2edd9db1b/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Bill Keese <[email protected]…>]

In 9de5f5c7f5df191596bab83a18e8871eeba1158e/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Bill Keese <[email protected]…>]

In b705fc4a494f78f9519a4df8979b94ac1cbb7fb5/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled?