Accidentally reloading/closing the browser tab closes the buffer and all input is lost

[TauPan]

Hi!

I love being able to edit textareas in emacs, thanks for your work!

I mishandled my keyboard focus yesterday and meant to search something in a shell history with Ctrl-R, but the browser was focused so I accidentally reloaded a page with a trac ticket I had been working on for a couple of minutes.

atomic-chrome (with the Atomic Chrome extension on chromium) immediately closed the buffer.

Reproducing it today it seems there is no way to retrieve the buffer contents except M-x view-lossage. There is no temporary file or anything (at least I can't find any).

It would be very neat if atomic-chrome.el could offer some assistance with accidents like these ;-)

[agzam]

Workaround to this issue I personally use, is to utilize the hook like this:

(defun ag/atomic-edit-done ()
  (kill-new (buffer-string) t)
  (when (eq system-type 'darwin)
    (shell-command "open -a \"Google Chrome\"")))

(add-hook 'atomic-chrome-edit-done-hook #'ag/atomic-edit-done)

here, it not only saves the text in the kill ring, but also automatically focuses on Chrome (if you're in OSX)

[TauPan]

Saving the buffer this way is a good idea. Also focusing on chrome. (A bit different for me on linux.) That's a good workaround, thanks!

[TauPan]

For the record: here's my take

;; from https://github.com/alpha22jp/atomic-chrome/issues/34#issuecomment-368374363
(defun fdf/atomic-edit-done ()
  (kill-new (buffer-string) t)
  (when (eq system-type 'gnu/linux)
    (shell-command "xdotool search browser windowraise windowactivate")))
(add-hook 'atomic-chrome-edit-done-hook #'fdf/atomic-edit-done)

Just tested with this textarea here, works nicely.

[sten0]

@TauPan @agzam I agree, this should be fixed, because it's a serious enough issue that it could cause new users to quit—speaking for myself, someone who never rage quits, encountering this bug would definite cause me to give up on atomic-chrome. I'm planning to start using atomic-chrome tonight btw, and always check the issue tracker [edit: of software I'm considering using] for stuff like this.

Would one of you please file a PR since it's your solution?

[TauPan]

@TauPan @agzam I agree, this should be fixed, because it's a serious enough issue that it could cause new users to quit—speaking for myself, someone who never rage quits, encountering this bug would definite cause me to give up on atomic-chrome. I'm planning to start using atomic-chrome tonight btw, and always check the issue tracker [edit: of software I'm considering using] for stuff like this.

Would one of you please file a PR since it's your solution?

My solution to focus the browser depends on xdotool being installed, which is not guaranteed. If you leave that out it's all @agzam's code and idea.

[sten0]

@TauPan @agzam I agree, this should be fixed, because it's a serious enough issue that it could cause new users to quit—speaking for myself, someone who never rage quits, encountering this bug would definite cause me to give up on atomic-chrome. I'm planning to start using atomic-chrome tonight btw, and always check the issue tracker [edit: of software I'm considering using] for stuff like this.
Would one of you please file a PR since it's your solution?

My solution to focus the browser depends on xdotool being installed, which is not guaranteed. If you leave that out it's all @agzam's code and idea.

@TauPan good point. From a Debian perspective I could make the package depend on xdotool or wmctrl (which I'm much more familiar with), but that I suspect it wouldn't work properly for users on Wayland.

@alpha22jp maybe the best way to solve this would be to contact the Atomic Chrome and GhostText plugin developers and ask for connection state tracking? That way, if the websocket was interrupted by a refresh event then the Emacs side could maintain the buffer for a period of time (possibly via configurable timeout), and then push the buffer into the text input field once the page refreshes. Also, it seems to me that the ideal would be if there was some sort of websocket session tracking that could be leveraged to this end, and that would also allow multiple associations between multiple buffers to multiple text entry areas.

[sten0]

@TauPan @agzam I agree, this should be fixed, because it's a serious enough issue that it could cause new users to quit—speaking for myself, someone who never rage quits, encountering this bug would definite cause me to give up on atomic-chrome. I'm planning to start using atomic-chrome tonight btw, and always check the issue tracker [edit: of software I'm considering using] for stuff like this.
Would one of you please file a PR since it's your solution?

My solution to focus the browser depends on xdotool being installed, which is not guaranteed. If you leave that out it's all @agzam's code and idea.

Oh my, I was just bitten by a github issue on this topic, while replying :-/ If you click 'edit' to edit a message, then close the tab, you lose the original unedited message WTF. Anyways, @TauPan, Good point, I agree. Also, while I could make the Debian package depend on xdotool (or wmctrl, which I'm much more familiar with), I'm not sure if this would work for users on Wayland. Probably not.

@alpha22jp It seems to me that the best way to solve this would be to approach the Atomic Chrome and GhostText developers about adding websocket session connection tracking support. If the connection is interrupted by something like a refresh than the Emacs side could cache the buffer for a configurable time period. Websocket session tracking could also provide a method to access multiple text-entry areas, each associated 1-to-1 with their own buffer. In case of a refresh, the plugin would reuse the same identifier, and the Emacs side would then grab it and push the cached changes to the text entry field in the newly reloaded page. It might even be possible to associate one buffer to multiple text-entry areas to post to multiple sites simultaneously.

[mpereira]

I just lost a buffer I was working on for a couple of hours...

[mpereira]

Another workaround is preventing buffers opened from atomic-chrome sessions to be killed: #52 (comment)