An edit is lost when the page reloads right after Escape

Open
  • Is something wrong?
#1,480 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
sqlite
Domain
database

Research direction

Start by tracing the editor save path through the async steps that build outliner ops and post apply-outliner-ops, then inspect how the worker acknowledges the sqlite transaction. Reproduce with the described Escape and reload timings; done means an edit survives reload during the reported window. The issue lists several possible designs and leaves the choice to maintainers.

Written by the indexing model from the issue text.

Description

An edit is lost when the page reloads right after Escape

Type in a block, press Escape, and reload within about 150 ms: the edit is gone after the reload (no block in the database holds it). At 500 ms it is kept. On an idle machine the window is short; on a loaded one it is wide enough to hit by hand.

Found by a local key fuzzer that types a unique token into the focused block editor, presses Escape twice, waits 0, 150 or 500 ms, reloads, and then queries the database for the token (logseq.api.datascript_query): 7 of 118 such checks lost the token, all at 0 or 150 ms, none at 500 ms, with varied preceding steps. A fresh page on an idle machine kept the edit 24 of 24 times.

Where the edit is lost

The worker writes a transaction to sqlite synchronously once it has it, so the loss is between Escape and the save reaching the worker: the save builds its outliner ops through several async steps before apply-outliner-ops posts them, and a reload in that time drops them. Nothing in the web app holds or flushes a pending save on unload: there is no beforeunload or pagehide handler for it.

Possible directions
  • On pagehide, post whatever the editor still holds synchronously (the save would need a synchronous path for that).
  • While a save is in flight, set a beforeunload handler so the browser asks before leaving (and the desktop app waits for it before closing the window).
  • Keep the editor's content somewhere that survives the reload (session storage) until the worker has acknowledged the save, and replay it on start.

Each changes how saving works, so this is a question for the maintainers rather than a patch.

Dominant language
No language data
Stars
29
Forks
2
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from logseq/db-test

All issues in logseq/db-test

Similar issues

More Databases issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.