[FEATURE REQUEST] Unhandled Time Features

[tungs]

This issue is meant to house references to real time currently handled and unhandled by timeweb. The handled features may eventually be moved to the README or wiki.

Scope

timeweb is intended only to cover cases where JavaScript can overwrite time-handling functions and elements in browser. Anything outside of it are considered out of scope.

Handled Cases

• setTimeout(), cancelTimeout()
• setInterval(), cancelInterval()
• requestAnimationFrame(), cancelAnimationFrame()
• Date.now(), performance.now()
• new Date()
• new CustomEvent().timeStamp

Partially Handled Cases

• video elements -- video playing is aimed to be handled by pausing the video and seeking to the frame as needed. Some event dispatching is handled, though there is still unintended event dispatching that isn't entirely handled.
  • video.currentTime should be handled

Unhandled Cases

Probably Possible

• requestIdleCallback Seems like the normal implementation might work in most cases, though the real time timeout may not interact with other timeouts as intended. May want to move this to the virtual timeline anyway, for more deterministic behavior

Might Be Possible, with Some Work

• Web Animations, longer discussion in #4 Also see element.animate, document.timeline, and DocumentTimeline
• SMIL Animations -- Also see [FEATURE REQUEST] Support for Declarative (SMIL) Animation timecut#39

Probably Out of Scope

• CSS Transitions -- Unless there's a library/polyfill that disables CSS Transitions and reimplements them via JavaScript, it's most likely outside of scope
• CSS Animations -- This might be possible by stopping animations and then providing a time-offset, though this might require CSS and selector parsing which would be a significant challenge
• Real-time processors of Audio and Video
• Event Dispatching -- This is pretty low level, so I wouldn't be surprised if it is out of scope. It may be possible to add an event listener that prevents dispatching (this already happens with videos) to every element that tries to add a listener, though this would likely be expensive. There'd also be a need to use a MutationObserver to detatch event listeners declared in DOM and then reattach them after the new dispatcher is attached.
• event.timeStamp -- it looks like the the property .timeStamp can be overwritten via Object.defineProperty(Event.prototype, 'timeStamp', { get: ... }) (see the implementation of CustomEvent), but actually setting the creation time at creation requires overwriting or hooking into the constructor. Making a new constructor for Event does not seem to overwrite normally dispatched events that inherit from Event. It may be possible to hook into other methods that would set a virtual creation time, though I can imagine cases where no other method or object is accessed between creation and usage (for instance, if one is using event dispatch and retrieval it in lieu of a setTimeout).