[Webkit-unassigned] [Bug 64786] The value of a number input form continues to increase/decrease even if we disable the input form.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=64786





--- Comment #17 from Kentaro Hara <haraken at google.com>  2011-07-19 23:21:45 PST ---
> > I guess that what we need to check is whether the second increment/decrement happens or not. How can we know it by watching the 'input' event?
> > 
> > We need to distinguish the following two cases:
> > 
> > Actual behavior (without this patch):
> > (1) 'mousedown' -> 'mouseup' -> 'input'  : the first 'input' event
> > (2) the repeating timer is fired  : the second 'input' event
> > 
> > Expected behavior:
> > (1) 'mousedown' -> 'mouseup' -> 'input'  : the first 'input' event
> > (2) nothing happens.
> 
> Ok, let's use setTimeout(..., 51 or more) in the 'input' handler.
> Smaller timeout is safer than 600ms/500ms timeout.

Sorry but I am confused... Why can we shorten the time by using setTimeout() in the 'input' event?

(1) the 'mousedown' event is triggered. 
(2) the 'mouseup' event is triggered. 
(3) the 'input' event is triggered. 
(4) the repeating timer is fired first. 
(5) the repeating timer is fired second. 

In my understanding, initialAutoscrollTimerDelay (250ms) is the time between (2) and (4), and autoscrollTimerDelay (50ms) is the time between (4) and (5). And the time between (2) and (3) is small enough. In this way, even if we use setTimeout() in the 'input' event, I think that we cannot shorten the waiting time less than 250ms. 

In case where the delay is long, we may be able to shorten the time by using setTimeout() inside the setTimeout() in the 'mouseup' event, but I am afraid that it degrades readability.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.