Changes between Initial Version and Version 2 of Ticket #13385

Jul 9, 2011, 2:12:27 AM (9 years ago)

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.


  • Ticket #13385

    • Property Cc Douglas Hays added
    • Property Component changed from Dijit - Form to Dijit
    • Property Summary changed from NumberSpinner hover color not reset (Claro theme) to lingering hover state when mouse moved quickly
    • Property Milestone changed from tbd to 2.0
    • Property Owner changed from Douglas Hays to bill
  • Ticket #13385 – Description

    initial v2  
    11To reproduce:
    3    - Create NumberSpinner
    4    - Move cursor into text box of NumberSpinner (color changed)
     3   - Create !NumberSpinner
     4   - Move cursor into text box of !NumberSpinner (color changed)
    55   - Move cursor into content of the arrows (not the *borders*)
    66   - Move cursor out of arrows (not back into text box)
    99Notice 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.
    11 Test it with the latest versions of Chrome and FireFox.
     11Test it with the latest versions of Chrome and !FireFox.
    1313Strangely, IE9 doesn't have this problem, although earlier versions do.