#14743 closed defect (fixed)
typematic surpresses events unnecessarily
Reported by: | bill | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | undecided | Milestone: | 1.8 |
Component: | Dijit | Version: | 1.7.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Starting from the initial checkin in [7522], typematic stops propagation for a number of events.
The current code is:
on(node, "mousedown", lang.hitch(this, function(evt){ event.stop(evt); typematic.trigger(evt, _this, node, callback, node, subsequentDelay, initialDelay, minDelay); })), on(node, "mouseup", lang.hitch(this, function(evt){ if(this._obj){ event.stop(evt); } typematic.stop(); })), on(node, "mouseout", lang.hitch(this, function(evt){ event.stop(evt); typematic.stop(); })), on(node, "mousemove", lang.hitch(this, function(evt){ evt.preventDefault(); })), on(node, "dblclick", lang.hitch(this, function(evt){ event.stop(evt); if(has("ie")){ typematic.trigger(evt, _this, node, callback, node, subsequentDelay, initialDelay, minDelay); setTimeout(lang.hitch(this, typematic.stop), 50); } }))
I didn't test it, but seems like at a minimum the event.stop() calls will interfere with widgets or apps that are trying to monitor these events at a higher level, for example:
<div data-dojo-type=dijit.form.NumberSpinner onMouseMove="...">
(mouse movement over the up/down arrows won't be reported, will it?)
I also don't see a reason for the code to be there. In particular the mousemove handling seems strange since mouse movement doesn't have anything to do with typematic, does it?
Compare to [27394] where I had to add back the propagation of mousedown.
Change History (3)
comment:1 Changed 9 years ago by
Owner: | set to Douglas Hays |
---|---|
Status: | new → assigned |
comment:2 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 9 years ago by
Milestone: | tbd → 1.8 |
---|
Note: See
TracTickets for help on using
tickets.
In [27994]: