Visual Desynchronization during Concurrent Element Movement in Shared Designs

Short answer

Based on how real-time collaborative design editors are generally built, the lock almost certainly wins over the group translation, and out-of-order movement packets are resolved by server-side ordering rather than by merging positions. One important caveat up front: Canva's synchronization engine is proprietary and not publicly documented, so the specifics below describe well-established patterns in collaborative editors, not confirmed Canva internals. Treat this as the likely explanation, and verify against Canva's own support documentation if you need an authoritative statement.

Why the lock state takes priority

A lock in a collaborative editor is normally enforced at the application layer as a permission check, applied before a mutation is accepted into the shared state. It is not just another property competing in the merge. When a collaborator drags a group containing a locked element, the typical outcomes are:

• The server rejects or reverts the move because it would reposition a locked child.
• The group move is constrained so the locked child stays fixed (less common, more complex to implement).
• The collaborator sees the drag locally (optimistic update), then watches the element snap back once the server's authoritative state arrives.

That snap-back is the visible signature of server-side rejection. So in the admin-locks-while-collaborator-drags scenario, the expected end state is: the locked element remains where the admin's lock left it, and the collaborator's conflicting translation is discarded or partially applied to the unlocked siblings.

How out-of-order movement packets resolve

Concurrent moves of the same element are almost never merged into an averaged position. The standard approach is last-writer-wins keyed on a server-assigned ordering — sequence numbers or timestamps applied when the server processes each update, not when the client sent it. This matters under high latency:

1. Each client applies its own move immediately (optimistic rendering), which is why both users briefly see different positions.
2. The server assigns a definitive order to the incoming updates.
3. All clients reconcile to the server's state, so whichever update the server ordered last determines the final position.

The desynchronization you observe is therefore transient by design. Once sync packets settle, every client should converge. If divergence persists after the network recovers, that indicates a dropped update or a client bug, not intended conflict resolution.

The grouped-element wrinkle

Groups typically store child coordinates relative to the group origin. Moving the group transforms only the origin, which is why a locked child creates a genuine conflict: honoring the group move would implicitly move the locked element. This is the strongest reason to expect the engine to block or revert the group translation rather than silently reposition the locked child — the alternative would make locks meaningless inside groups.

How to verify the actual behavior

Because the internals are unconfirmed, a quick empirical test settles it:

1. Open the same design in two browsers with two accounts. In one, throttle the network using browser devtools (e.g., add 500–1000 ms latency).
2. As the admin, lock an element inside a group while the collaborator drags that group.
3. Watch the collaborator's client: if the element snaps back after sync settles, the move was rejected server-side and the lock won.
4. Optionally inspect WebSocket frames in devtools' Network tab to see whether move events for the locked element are acknowledged or rejected.

Note that lock semantics may vary by role (owner vs. collaborator) and by product tier, and offline or cached states in desktop and mobile clients can change reconciliation timing. One detail that would sharpen this answer: whether the collaborator's client shows a snap-back or an immediate drag rejection — that distinguishes server-side rejection from client-side lock enforcement.