Improve cross-realm portability of editor animation frames

[hiroshisuga]

What does this PR do?

This PR makes editor-related animation frames use the window that owns the editor container instead of implicitly using the global window. Thus this would make a good workaround to the problem posted here: bigbluebutton/bigbluebutton#25597 on the second part.

It adds editor.getContainerDocument() and editor.getContainerWindow(), and uses the container window for requestAnimationFrame() / cancelAnimationFrame() calls in the editor and tldraw packages.

This improves the portability of this tldraw fork when the editor is rendered in a different browser window, and brings the fork closer to the direction taken by upstream tldraw.

It also prepares the fork for future BigBlueButton use cases where the whiteboard or presentation may be rendered in another window without replacing global browser APIs, for instance, bigbluebutton/bigbluebutton#25461

Relation to upstream

Upstream tldraw has moved in the same general direction by avoiding assumptions about the global browser realm and by introducing broader timer abstractions.

This PR intentionally takes a smaller approach for this older fork; rather than backporting the complete upstream timer infrastructure, editor-level animation frames directly use: editor.getContainerWindow()

This is sufficient for the current cross-window requirements and keeps the change limited to the editor and tldraw packages.

Generic timer helpers in lower-level packages are left unchanged because they do not have access to an editor container. Extending the change to those packages would require a quite larger backport.

The goal here is to make the minimum practical change needed to improve cross-window portability while keeping the fork stable and easy to maintain.

Compatibility

Normal single-window tldraw behavior is unchanged.

In the usual case, the editor container belongs to the application's current window, so editor.getContainerWindow() resolves to the same window that was previously used implicitly.

The behavior only differs when the editor is actually hosted in another browser window.

TickManager - a relatively large change

TickManager also remembers the window used when requesting a frame so that the frame is cancelled through the same window, even if the editor container moves between windows.

Change Type

• patch — Bug fix
• minor — New feature
• major — Breaking change
• dependencies — Changes to package dependencies¹
• documentation — Changes to the documentation only²
• tests — Changes to any test code only²
• internal — Any other changes that don't affect the published package²
• I don't know

Test Plan

1. Build and run tldraw normally and verify standard editor behavior.
2. Verify drawing, selection, zooming, panning, and UI interactions.
3. Render the editor in another browser window and verify the same operations ([3.0 feat] Detachable presentation, showing next slide and presenter's note bigbluebutton#25461 does it).
4. Confirm that no global requestAnimationFrame / cancelAnimationFrame replacement is required.

• Unit Tests
• End to end tests

Release Notes

• together with Backport upstream cross-realm HTMLElement fix #54, tldraw would become practically portable.

Footnotes

1. publishes a patch release, for devDependencies use internal ↩

2. will not publish a new version ↩ ↩² ↩³