I'm a bit stuck due to the way (auto)save is currently done. The autosave orchestration is done *clien-side* which means:
there is a request to save the page, which can lead to a merge conflict
then the new version number (returned by the save request) is propagated to the rest of the editors
I cannot trigger autosave too often because it floods the page history, so I'm left with triggering autosave when:
web page visibility changes to hidden (e.g. when you switch the browser tab or window) -> done already
the user navigates away or closes the window/tab -> not easy to do currently because when the window unloads I can only send a beacon for which you can't handle the response. So I can't propagate the new version to the rest of the editors. Not to mention that I could get a merge conflict.
I could do the second point only for the last user left in the realtime editing session, in order to remove the need to propagate the new version, but the user could still lose content if there is a merge conflict. To overcome this we could do the last save (on window unload) without passing the original version in order to force overwrite whatever there is on the database, arguing that it's better to revert if needed than to lose content.
Ideally the orchestration should be done *server-side*, and the client side would only need to care about pushing the latest changes, which can be done with a beacon on window unload. But this needs some refactoring.
It would also help to implement document drafts in order to remove the need to handle merge conflicts on autosave. The autosave would update only the draft, which is associated to the realtime session, so there should be no merge conflicts. Then the user would have to merge the draft in the original document manually, when they think the content is ready.
Marius Dumitru Florea on 18/Sep/25 14:10
I'm a bit stuck due to the way (auto)save is currently done. The autosave orchestration is done **clien-side** which means:
* there is a request to save the page, which can lead to a merge conflict * then the new version number (returned by the save request) is propagated to the rest of the editors
I cannot trigger autosave too often because it floods the page history, so I'm left with triggering autosave when:
* web page visibility changes to hidden (e.g. when you switch the browser tab or window) -> done already * the user navigates away or closes the window/tab -> not easy to do currently because when the window unloads I can only [send a beacon|https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon] for which you can't handle the response. So I can't propagate the new version to the rest of the editors. Not to mention that I could get a merge conflict.
I could do the second point only for the last user left in the realtime editing session, in order to remove the need to propagate the new version, but the user could still lose content if there is a merge conflict. To overcome this we could do the last save (on window unload) without passing the original version in order to force overwrite whatever there is on the database, arguing that it's better to revert if needed than to lose content.
Ideally the orchestration should be done **server-side**, and the client side would only need to care about pushing the latest changes, which can be done with a beacon on window unload. But this needs some refactoring.
It would also help to implement document drafts in order to remove the need to handle merge conflicts on autosave. The autosave would update only the draft, which is associated to the realtime session, so there should be no merge conflicts. Then the user would have to merge the draft in the original document manually, when they think the content is ready.
Marius Dumitru Florea on 18/Sep/25 14:10
I'm a bit stuck due to the way (auto)save is currently done. The autosave orchestration is done *clienclient-side* which means:
* there is a request to save the page, which can lead to a merge conflict * then the new version number (returned by the save request) is propagated to the rest of the editors
I cannot trigger autosave too often because it floods the page history, so I'm left with triggering autosave when:
* web page visibility changes to hidden (e.g. when you switch the browser tab or window) -> done already * the user navigates away or closes the window/tab -> not easy to do currently because when the window unloads I can only [send a beacon|https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon] for which you can't handle the response. So I can't propagate the new version to the rest of the editors. Not to mention that I could get a merge conflict.
I could do the second point only for the last user left in the realtime editing session, in order to remove the need to propagate the new version, but the user could still lose content if there is a merge conflict. To overcome this we could do the last save (on window unload) without passing the original version in order to force overwrite whatever there is on the database, arguing that it's better to revert if needed than to lose content.
Ideally the orchestration should be done **server-side**, and the client side would only need to care about pushing the latest changes, which can be done with a beacon on window unload. But this needs some refactoring.
It would also help to implement document drafts in order to remove the need to handle merge conflicts on autosave. The autosave would update only the draft, which is associated to the realtime session, so there should be no merge conflicts. Then the user would have to merge the draft in the original document manually, when they think the content is ready.
Marius Dumitru Florea on 18/Sep/25 14:11
I'm a bit stuck due to the way (auto)save is currently done. The autosave orchestration is done *client-side* which means:
* there is a request to save the page, which can lead to a merge conflict * then the new version number (returned by the save request) is propagated to the rest of the editors
I cannot trigger autosave too often because it floods the page history, so I'm left with triggering autosave when:
* web page visibility changes to hidden (e.g. when you switch the browser tab or window) -> done already * the user navigates away or closes the window/tab -> not easy to do currently because when the window unloads I can only [send a beacon|https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon] for which you can't handle the response. So I can't propagate the new version to the rest of the editors. Not to mention that I could get a merge conflict.
I could do the second point only for the last user left in the realtime editing session, in order to remove the need to propagate the new version, but the user could still lose content if there is a merge conflict. To overcome this we could do the last save (on window unload) without passing the original version in order to force overwrite whatever there is on the database, arguing that it's better to revert if needed than to lose content.
Ideally the orchestration should be done **server-side**, and the client side would only need to care about pushing the latest changes, which can be done with a beacon on window unload. But this needs some refactoring.
It would also help to implement document drafts in order to remove the need to handle merge conflicts on autosave. The autosave would update only the draft, which is associated to the realtime session, so there should be no merge conflicts. Then the user would have to merge the draft in the original document manually, when they think the content is ready.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
