NumberSpinner: lingering hover state when mouse moved quickly

[Stephen Chung]

To reproduce:

• Create NumberSpinner
• Move cursor into text box of NumberSpinner (color changed)
• Move cursor into content of the arrows (not the *borders*)
• Move cursor out of arrows (not back into text box)
• Color of text box is not reset, still blue

Notice that if you move the cursor first onto the *borders* of the *arrows* then move out, the color will be reset. Therefore, only moving from the *content* of the arrows will have this error.

Test it with the latest versions of Chrome and FireFox.

Strangely, IE9 doesn't have this problem, although earlier versions do.

[Douglas Hays]

This is a timing problem with _CssStateMxin.js
When the mouse moves quickly from the button node to the document body, then a mouseleave event on the button node is generated but not a mouseleave from the widget domNode. But the mouseleave event's relatedTarget is a node outside the widget but this information is ignored.

                cn("onmouseleave", function(){
                        hovering = false;
                        active = false;
                        setClass();
                });

should be something like:

                cn("onmouseleave", function(evt){
                        hovering = false;
                        active = false;
                        setClass();
                        if(!dojo.isDescendant(evt.relatedTarget, this.domNode)){
                                self._set("hovering", false);
                                self._set("active", false);
                        }
                });

[bill]

Hmm, that sounds like a browser bug although I suppose there's some fine print somewhere saying that mouseleave events aren't reliable.

Doug - your solution will work for this case, but it's depending on the sub-node being registered with _CssStateMixin, via this code in _Spinner.js:

cssStateNodes: {
	"upArrowNode": "dijitUpArrowButton",
	"downArrowNode": "dijitDownArrowButton"
},

If there wasn't a mouseout event handler registered for NumberSpinner.upArrowNode etc, then the problem comes back.

For 2.0, or maybe earlier, I plan to use switch to using CSS pseudo-classes (:hover, :active, :focus), at which point this problem will be resolved. Not sure if it's worth [partially] fixing before that.

[Colin Snover]

Bulk update of open ticket priorities.

[bill]

Fixed indirectly in [27513].