Error (websocket): in callback `on-message': JSON readtable error

[stapelberg]

Every once in a while, a *Warnings* buffer pops up, displaying error messages such as:

Error (websocket): in callback `on-message': JSON readtable error: 89
Error (websocket): in callback `on-message': JSON readtable error: 65
Error (websocket): in callback `on-message': JSON readtable error: 66

This is with websocket 20190621.54 from MELPA with:
GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.4)
of 2019-02-03, modified by Debian

[ahyatt]

In this case, I'm assuming you are parsing JSON that comes out of the websocket layer, in the on-message callback?

If so, it sounds like either the JSON being sent is bad or that maybe the websocket layer is dropping some bytes. Do you have a reproducible example?

[stapelberg]

No reproducible example unfortunately, I haven’t yet picked up on what the pattern is. Last I noticed this was when I was working on some .asciidoc files.

[danielquinlan]

I'm getting a similar error when using websocket.el with atomic-chrome.el (to use Emacs to edit text from a text edit box in Chrome).

Error (websocket): in callback `on-message': Bad string format: "?\\C-@" Error (websocket): in callback `on-message': JSON readtable error: 101

It happens when trying to edit Wikipedia articles like https://en.wikipedia.org/w/index.php?title=Kmart&action=edit using the source editor (not the visual editor, of course).

I'm able to edit .js and .css files on Wikipedia without errors. It seems like it may be specific to the wikitext format.

[ahyatt]

I'm guessing this is an error with the websocket client - note that it is an issue in the callback, and with JSON, which websocket doesn't deal with. Perhaps we're doing some wrong encoding, which maybe is possible.

I haven't used atomic-chrome, but I tried it out and it seemed to not work for a different reason: it is assuming a frame is complete. In the exact article you point to, when I send it, the first frame isn't complete and completep is set to non-nil. So when it comes time to parse it in atomic-chrome-on-message, it cannot be parsed to JSON because it isn't a completely JSON object yet. The solution is for atomic-chrome-on-message to handle incomplete frames (or perhaps for our websocket library to optionally combine frames).

I'll create a bug with them alerting them of this fact. The bug you reported may be a different bug, though.