setInterval should clamp the maximum delay

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: Aaron McBride, Unassigned)

Tracking

15 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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?
Component: Untriaged → DOM
Product: Firefox → Core
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.