Using Timeout/Interval with millis >= i32::MAX results in incorrect behavior

[arthurprs]

Describe the Bug

Millisecond arguments are taken as u32 and internally cast (unchecked) to i32. Leading to the timer/interval firing after the wrong duration.

Look for millis as i32, in the examples bellow.

Example 1.

gloo/crates/timers/src/callback.rs

Lines 98 to 109 in 2c9e776

	pub fn new<F>(millis: u32, callback: F) -> Timeout
	where
	F: 'static + FnOnce(),
	{
	let closure = Closure::once(callback);
	let id = GLOBAL.with(|global| {
	global
	.set_timeout_with_callback_and_timeout_and_arguments_0(
	closure.as_ref().unchecked_ref::<js_sys::Function>(),
	millis as i32,
	)

Example 2.

gloo/crates/timers/src/callback.rs

Lines 200 to 211 in 2c9e776

	pub fn new<F>(millis: u32, callback: F) -> Interval
	where
	F: 'static + FnMut(),
	{
	let closure = Closure::wrap(Box::new(callback) as Box<dyn FnMut()>);
	let id = GLOBAL.with(|global| {
	global
	.set_interval_with_callback_and_timeout_and_arguments_0(
	closure.as_ref().unchecked_ref::<js_sys::Function>(),
	millis as i32,
	)

Steps to Reproduce

Use the timer/interval with (u32::MAX / 2) as the duration, they'll fire immediately.

Expected Behavior

Either

1. Panic if duration is larger than the JS runtime supports.
2. Error result (breaking change)
3. Clamping it to 0..=i32::MAX before sending to the JS runtime.

Actual Behavior

See description.

Additional Context

N/A

[DesmondWillowbrook]

Looks like this is a very old bug in the JS spec?

https://stackoverflow.com/questions/3468607/why-does-settimeout-break-for-large-millisecond-delay-values

Should we patch over this behavior? Since it will be deviating from default JS behavior which is to fire immediately.