Last Comment Bug 795373 - setInterval should clamp the maximum delay
: setInterval should clamp the maximum delay
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 15 Branch
: x86_64 Windows 7
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2012-09-28 10:10 PDT by Aaron McBride
Modified: 2012-09-28 16:29 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Aaron McBride 2012-09-28 10:10:26 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4

Steps to reproduce:

Called setInterval with a very large delay (300000000000ms).

Actual results:

The delay was treated as 0.

Expected results:

If Firefox can't handle a delay that large, it should clamp to the largest that it can handle.
Comment 1 User image Aaron McBride 2012-09-28 10:12:20 PDT
Here's a simple test to run in the console:
setInterval(function () { console.log('test') }, 300000000000)

It appears that the maximum usable delay is 2^31 - 1.  It seems like the delay would be safe to store in an unsigned int, but in any case... why not clamp at 2^31 - 1?
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2012-09-28 16:29:51 PDT
The current implementation uses a standard ToInt32 conversion as defined in the ECMA spec to convert the given value to an interval.

And that's the right behavior per spec, which says:

  long setInterval(Function handler, optional long timeout, any... arguments);

"long" in IDL means "signed 32-bit int".

Please feel free to raise this as a spec issue if you think the spec should change, of course.  For example if you think it should use [Clamp] on that argument.

Note You need to log in before you can comment on or make changes to this bug.