I'd like to look at this before it merges. I want to make sure the changes don't open a hole in our GC story for values captured in task closures.

I don't believe this is safe right now.

1. ScriptThread::timer_scheduler is marked no_trace
2. the scheduler contains BoxedTimerCallback values that can move arbitrary values into a closure
3. as long as those callbacks were required to be Send, we could rely on none of our GC types being Send and therefore preventing GC values stored in an opaque closure. Now we're lifting that restriction but the scheduler is still opaque to the GC

I don't believe this is safe right now.

Ok I see, so basically the current changes are in fact safe, because the cell is not a rooted type, but for example my suggestions at #37984 (using a Dom<GlobalScope> in a callback) would be definitely a bad idea(but the current code is safe, because it uses Trusted).

Thanks for catching this.

If we were to use the NonSendTaskOnce proposed at #37762, then we'd need to have a script specific timer scheduler that would be js traceable, right?

How about separating the queue of callbacks from the timer scheduler itself?

For example:

• schedule_timer take a usize(and a duration), which is the position of the callback in the queue.
• dispatch_completed_timers returns a list of positions. It's up to the surrounding environment to then dispatch the assosiated callbacks. This would mean that in script we can store the callbacks somewhere where they will be traced.

EDIT: obviously one would use a hasmap, not a queue, since timers fire independently of their position in any queue.