All script thread execution starts in the ScriptThread event loop method, but anytime some code runs that needs to interact with the ScriptThread public APIs we end up fetching a singleton pointer that's stored in thread-local storage (

Per #36609 (comment), we know that TLS accesses in hot code paths show up in profiles, so it would be great to find a way to avoid this particular footgun, even if this particular use is not yet causing us troubles.

Some assorted ideas I have had:

• store a pointer to the ScriptThread in Window
• share subsets of data contained in ScriptThread behind Rc<RefCell<...>> so DOM objects can interact with the data directly instead of calling ScriptThread APIs (Rendering loop: replace the Arc<AtomicBool> with a Cell<bool> for has_pending_animation_tick in ScriptThread #37946 proposes moving some existing code away from this model)
• store a static mutable vector of ScriptThread pointers and store indexes into that vector in Window/other relevant code
• pass &ScriptThread arguments into common entrypoints (eg. tasks) so they can be passed down to the code that requires ScriptThread access