September 16, 2026
Why a save cannot be trusted to keepalive
Edits vanished when you moved between pages, and big saves never left the browser. Here are the two traps behind it and the single saver that fixes both.
Someone edits a project, clicks to another page, and comes back to find the last few seconds of work gone. The save did not fail loudly. It simply never happened. Three of our editors did this. Tracking it down taught us two things about the browser that most guides do not mention. One of them is about keepalive, a browser feature meant to finish a request as a page closes.
Trap one: moving between pages sends no warning
Every editor waits a moment before saving. You stop typing, a timer runs for two or three seconds, then it saves. If you close the page while the timer runs, the browser tells us, and we save right away.
But moving to another page inside genvi does not count as closing the page. The page does not unload, and the tab is not hidden. The editor simply disappears from the screen. Three of our editors threw away their waiting timer when that happened, so the last edits before you moved were lost. It was one of the eleven bugs found in our September review.
Trap two: a size limit nobody warns you about
When a save is sent as a page goes away, the browser offers a setting called keepalive. It lets the request finish after the page is gone. The catch is that the browser refuses requests over roughly 64 KB with this setting. Some of our saves include a small preview picture, which pushes them over that size. The save is not sent, and nothing tells you.
So the setting must be used only when the save is small enough. Our shared saver measures each save and turns the setting on only under the limit. That is also why a save made while the page is closing takes no preview picture.
What we built: one saver for everything
There were five different ways to save in the app. Each had its own waiting time, its own way to handle conflicts, and its own behaviour when you left. We replaced all five with one shared saver. Each editor only tells it whether it is ready and how to describe its work. The saver does the rest.
Four things make it dependable.
- Leaving sends the save. When an editor closes, the saver sends what is waiting. Moving between pages loses nothing.
- One save is waiting, never a line of them. A newer save replaces the waiting one. The content is gathered at the moment the timer fires, because what it looked like when the timer started is already out of date.
- A forced save takes the waiting one with it. Otherwise the waiting save would arrive later with older content and overwrite the newer work.
- A preview picture never holds up a save. We give the picture 4 seconds. If it is not ready, the save goes without it.
Some things only get to leave once, so make sure they are packed. Made with Recraft V4.1 Pro.
When two tabs save at once
Each save says which version of the project it was based on. If another tab or device saved a newer version in the meantime, the server says so. The saver then takes the newer version, so the next save works, and warns you instead of overwriting anything. There is now one way to handle this, where there used to be five.
How we make sure it stays fixed
Automatic tests look at the node studio, the video composer and the whiteboard. They confirm that a waiting save is remembered when the timer starts. They also confirm that it is cleared when the timer fires, so closing does not save twice. Saving still happens right away when you close the page or switch tabs. Nothing is saved before your project has loaded.
If someone removes the save-on-leave step, those checks fail. That is the test we ask of every check: it must fail when the change is undone.
The lesson is that the browser's warnings are not a complete list of ways a page can end. If your save depends on a warning, find out which exits do not send one.