An edit is lost when the page reloads right after Escape

Abierto
  • ¿Algo no está bien?
#1,480 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
sqlite
Área
database

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
29
Forks
2
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de logseq/db-test

Todos los issues de logseq/db-test

Issues similares

Más issues de Databases

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.