BUG: Previews in Firefox on Trac wikis confuse GhostText

[ntc2]

Setup

Browser: Firefox 64.0 on Ubuntu 18.04 Editor: Emacs 25.2.2

Description

When I preview my edits on a Trac wiki using GhostText in Firefox, GhostText gets confused. I have tested in Firefox with both Emacs and Sublime Text, and they have the same problem, so I think it's an issue with GhostText. Also, have tested in Chrome with both Emacs and Sublime Text and I don't have this issue, so I think it's an issue with Firefox+GhostText specifically.

The issue is a little hard to describe, but it's easy to reproduce. To reproduce, go to the Trac demo wiki at

https://trac.edgewall.org/demo-1.3

and choose "Edit this page", which will take you to

https://trac.edgewall.org/demo-1.3/wiki/WikiStart?action=edit

Now don't edit, just click on "Preview Page", which will take you to a preview at

https://trac.edgewall.org/demo-1.3/wiki/WikiStart

Now scroll up, select the text area with the wiki source, and start GhostText. GhostText will connect correctly and you can start editing. Makes some changes to the wiki source with your editor via GhostText, and then click on "Preview Page" again. The page will reload at

https://trac.edgewall.org/demo-1.3/wiki/WikiStart

again, with your changes rendered.

Now, the problem: the text area is no longer connected to GhostText, but the corresponding buffer in the editor is still open. If you make changes in the editor, nothing happens. If you click on the GhostText icon now, it closes the buffer in the editor and you lose your changes. Finally, if you click on the GhostText icon a second time GhostText opens a new buffer, and you can edit again, but your intermediate changes are still lost.

That's with Firefox. With Chrome, GhostText closes the buffer in your editor as soon as you click on "Preview Page", so there is no confusion, and no chance to lose your changes. Note that It's All Text! did even better with these Trac previews: it could keep the same buffer open across all "Preview Page" clicks, so you didn't have to load a new buffer after each prview, and you didn't lose your cursor position in the buffer each time. (Nevertheless, your plugin seems better than It's All Text! for most things, e.g. it does better on GitHub previews, and can edit the magic compose box in GMail. Thanks!!!)

[ntc2]

I've been using GhostText in FireFox for the last few days and it seems this kind of problem is more widespread than I thought. Another example is composing email in GMail (I'm using "plain text mode" in GMail if that's relevant). After I send my email the GhostText buffer in Emacs remains open, and if I start composing a new Email nothing happens in the GhostText buffer. On the browser side, GhostText claims it's still connected, but I have to stop and start GhostText before the Emacs buffer starts syncing the new email.

[fregante]

Can you test the new version? It hasn't been published to the stores yet: https://github.com/GhostText/GhostText/issues/172

[fregante]

Here's what happens in the newest version (not yet published)

1. The page reloads and thus the field no longer exists
2. The connection is closed on both the browser and sublime text (the moon becomes dark)
3. If you activate GhostText again, it correctly reenstabilishes the connection and sends the current text from the browser to the editor
4. The editor sees the same page and reuses the same tab
5. This overrides any changes you made in the editor… but you can still undo in Sublime Text to restore the previous version

Everything here is as expected, I don't know if this is different from what it was in the previous version.

The only "issue" I see is number 5, which you can avoid by setting new_window_on_connect: true in Sublime Text’s GhostText settings.

[fregante]

Sorry for the 2-years wait!