How should M3E Canvas handle editing across multiple browser tabs?

[CQMHV]

M3E Canvas currently auto-saves the entire document to a single localStorage key.

When the editor is opened in multiple browser tabs, each tab keeps its own in-memory state while writing to the same stored document. This means a change made in one tab can later be silently overwritten by another tab that was loaded from an older state.

Before proposing an implementation, I would like to clarify the intended behavior because there are several reasonable directions:

1. Single editable tab

   • Only one tab may edit the document.
   • Additional tabs open in read-only mode and can take over when the editing tab closes.

2. Cross-tab synchronization

   • Changes are propagated between tabs using the storage event or BroadcastChannel.
   • This would require defining how simultaneous or conflicting edits should be handled.

3. Independent documents per tab

   • Each document receives its own identifier and storage key.
   • Different tabs can then edit different documents independently.
   • This would likely grow into a broader multi-project workflow.

There is also a separate question about UI state such as zoom, panels, editor mode, and language: should it remain shared between tabs, or should some of it be tab-specific?

Would preventing concurrent writes with a single-tab editing lock be the preferred initial scope, or is independent multi-document editing closer to the intended direction?

I would be happy to implement the preferred approach in a PR once the expected behavior and scope are clear.

[lnkiai]

Thank you for laying the options out so clearly; you're right that today two tabs can silently overwrite each other.

Let's go with 1, a single editing tab: the first tab holds the document, later tabs open read-only with a short notice, and one of them can take over when the editing tab closes. It's the smallest change that removes the data loss, and it doesn't commit the app to conflict rules or a multi-document model that aren't on the roadmap.

UI state (zoom, panels, mode, language) can stay shared as it is now; nothing is lost if it's overwritten.

A PR along those lines would be very welcome. Keep it small, and it's fine if the read-only tab simply reloads to take over rather than syncing live.

[CQMHV]

Thanks, that scope makes sense. I have a small implementation ready: one tab holds the document lock, later tabs are read-only, UI state remains unchanged, and reloading after the editing tab closes takes over. I have also verified the two-tab flow locally and will prepare a focused PR.

[lnkiai]

Merged #60, thank you. Two small adjustments on my side after the merge:

• Where the browser has no Web Locks (an insecure origin such as a LAN address, or an older WebKit) the editor now works as it always did, without the guard, rather than refusing to edit. A single tab that cannot lock is more useful than none.
• The "checking edit access" indicator is gone; the check resolves too quickly to be worth a message.

The single-tab lock is live at https://lnkiai.github.io/m3e-canvas/. Closing this as resolved.