The hardest part of building a visual builder is not adding features.
It is making every action feel predictable.
Over the past week, we have continued working on the stability update we shared earlier.
The first major milestone is now complete: the view restoration and Layers synchronization issues passed repeated browser validation.
We confirmed that:
One wake-up transaction creates only one valid generation
Duplicate responses cannot trigger the same update twice
Inactive views restore into the correct page and view
Stale or mismatched responses are rejected
The correct view instance and editor frame are created during normal loading
Boot locks are released without leaving the builder stuck
The normal builder flow works without test-only recovery paths
We also found and corrected an issue in our own test runner.
The runner was accidentally replacing a read-only diagnostic channel with an empty array. That made a correct Settings transaction appear to fail, even though the product had processed it correctly.
This was an important reminder: validation tools need the same level of scrutiny as production code. A broken test can send development in the wrong direction just as easily as a broken feature.
After correcting the runner, we confirmed that Settings changes now produce:
One canonical Settings transaction
One correctly owned history command
The correct page and view identity
No duplicate Settings or text-edit commands
The remaining issue is now much smaller and more specific.
After a Settings transaction completed, an already-fired debounce timer could leave its old timer ID behind. When Undo was pressed later, the history system interpreted that stale ID as a pending text edit and created an unnecessary “Updated content” command.
The visible result could be:
Undo targeting an unexpected action
An extra history entry appearing
Settings Undo feeling unreliable
Redo no longer matching the exact original sequence
We traced this to a callback that exited early without clearing its completed timer state.
The new fix now:
Clears the timer state as soon as the callback runs
Rejects pending history work when there is no real active text or page edit
Preserves genuine text edits that still need to be committed before Undo
Prevents empty pending mutations from becoming history commands
We are currently validating two very focused scenarios in fully isolated browser profiles:
Change a Setting, wait, then Undo
No extra text command may appear.Edit real text, then press Undo before the normal debounce finishes
The real text edit must still be preserved and undone correctly.
We are deliberately testing these separately before reopening the broader suite.
The update is not finished yet, but the uncertainty is getting smaller:
View restoration: passed
Layers synchronization: passed
Normal builder boot: passed
Settings transactions: passed
Settings history ownership: passed
Settings-only Undo cleanup: in final validation
Real pending text Undo: in final validation
Broader Undo/Redo and multi-view regression tests: next
We could ship sooner by accepting “mostly correct.”
But Undo, saving, and view isolation are trust features. They need to behave correctly every time, not only during the happy path.
Which kind of progress update is most useful to you: technical root causes, visible user impact, or a simpler shipped-versus-in-progress checklist?
Replies