Skip to content

SD-2505 - fix: avoid UI stalls with on Typo.js example#2765

Open
chittolinag wants to merge 2 commits intomainfrom
gabriel/sd-2505-bug-spellcheck-significant-lag-on-load-and-when-typing
Open

SD-2505 - fix: avoid UI stalls with on Typo.js example#2765
chittolinag wants to merge 2 commits intomainfrom
gabriel/sd-2505-bug-spellcheck-significant-lag-on-load-and-when-typing

Conversation

@chittolinag
Copy link
Copy Markdown
Contributor

@chittolinag chittolinag commented Apr 9, 2026

Issue

  • Typo.js proofing work executed on the main thread, creating typing lag and unresolved imports for the worker bridge (./typoWorkerMessages, ./typoWorker).

Proposed solution

  • Use a worker implementation so the provider compiles and runs its spellcheck logic inside a dedicated Web Worker, keeping the UI responsive.

@linear
Copy link
Copy Markdown

linear bot commented Apr 9, 2026

@chittolinag chittolinag marked this pull request as ready for review April 9, 2026 16:51
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 02dbe3d671

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines +82 to +85
const onAbort = () => {
pending.delete(requestId);
cleanup();
reject(createAbortError());
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Prevent abort handler from dropping uncancelled worker checks

If a proofing batch takes longer than timeoutMs (10s default in ProofingSessionManager), this abort handler rejects immediately and removes the request from pending, but the worker keeps computing because no cancel message is sent. When the worker eventually posts its result, handleMessage drops it (if (!entry) return), so segment hashes are never updated and the same segments can keep timing out/retrying without ever producing accepted results. This regresses behavior for large/slow documents; either propagate cancellation to the worker or avoid rejecting until the worker run is actually stopped.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants