Skip to content

Conversation

@gfgkmn
Copy link

@gfgkmn gfgkmn commented Nov 21, 2025

The Bug

I found that GhostText doesn't update text boxes correctly after the first edit. After debugging with Emacs atomic-chrome, I discovered GhostText was sending cached/stale text instead of reading the current text box content.

What Happens

  1. Edit text box with GhostText first time - works fine ✅
  2. Edit same text box second time - Chrome doesn't update ❌
  3. Check what GhostText sends on third connection - it's sending its old cached value, not what's actually in the text box!

Example from my debugging

I spent hours debugging this with Emacs atomic-chrome and found two critical issues:

Experiment 1 - Manual Edit Detection:

  1. Started with Chrome text box: "this is first string"
  2. Used GhostText to edit it to: "this is second string" ✅ (worked)
  3. Manually typed in Chrome to make it: "this is second string, this is my manual added string outside atomic"
  4. Triggered GhostText again
  5. BUG: GhostText sent to Emacs: text=[this is second string] (its cached value)
  6. Should have sent: text=[this is second string, this is my manual added string outside atomic] (actual content)

Experiment 2 - State Divergence:

  1. Chrome text box: "this is first string"
  2. GhostText edit → "this is second string" ✅ (Chrome updates correctly)
  3. GhostText edit → "this is third string" ❌ (Chrome stays at "second string")
  4. GhostText edit → "this is fourth string" ❌ (Chrome still shows "second string")
  5. The weird part: On the third GhostText connection, it sent text=[this is third string] to Emacs!

This proved GhostText has internal state ("third string") that's completely disconnected from Chrome's actual DOM content ("second string"). After the first edit, GhostText loses its ability to update Chrome but doesn't know it, and keeps using its stale cached values.

WebSocket debugging showed:

  • First connection: Port 62889 - works perfectly
  • Second connection: Port 62920 - new connection created, but Chrome won't accept updates
  • GhostText creates new connections but can't read current DOM content

The only workaround was refreshing the page between edits, which resets GhostText's connection to the DOM.

The Fix

For advanced editors (like CodeMirror, iPython notebooks, etc.), GhostText needs to request fresh content before sending. I added code to:

  1. Check if it's an advanced editor
  2. Fire a gt:get event to refresh the cached value
  3. Wait 50ms for the update
  4. Then send the actual current content

Testing

I tested this with:

  • iPython notebook text cells (where I first noticed the bug)
  • Regular text boxes
  • Multiple edit cycles without page refresh

Now it correctly reads the current content every time instead of using stale cache.

Why This Matters

Without this fix, you have to refresh the page between edits when using GhostText with any JavaScript-enhanced text editor. Super annoying when you're trying to quickly edit notebook cells or code comments.

The debugging process with Emacs atomic-chrome helped identify that the issue was GhostText sending wrong data, not a problem with the editor connection.


## Commit Message

Fix stale cache issue for advanced text editors

GhostText was sending cached values instead of current text box
content on reconnection. Added cache refresh for AdvancedTextWrapper
to request fresh values before sending.

Tested with iPython notebooks where the bug was most noticeable.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant