jTox crashes trying to send a long text

moorchegue commented 5 years ago

It gets worse: after restart it would try to send the message again and crash again, and so on.

Another problem is that unsent messages can't be removed by long press -> delete. Once you long press such a message the screen dims and there's no menu items visible. I suppose they're somewhere beyond the screen bounds?

Is there any other way to gently remove the message from sending queue without losing all the data? If that's a no would wiping history do the trick? I'm hesitant to try because I don't really want to risk losing my history to find out that it doesn't clear the unsent message queue.

The text message is a public PGP key, if that matters. I don't know if it can be reproduced with any key or this particular one, but I can share it if needed.

almindor commented 5 years ago

Hey, I need to reproduce this first but to get you unstuck you could fix this via ssh or terminal app (developer tools).

If you're able to ssh into your phone (using development mode with remote access turned on in settings) or use the terminal on the phone directly you can:

Turn jTox off
SSH/log into into the phone terminal as nemo user
sqlite3 ~/.local/share/harbour-jtox/harbour-jtox/jtox.sqlite
Check how many pending offline send messages are in your queue with SELECT count(*) FROM events WHERE event_type = 5;
Confirming number in step four, proceed to delete the pending messages with DELETE FROM events WHERE event_type = 5;
Exit sqlite/terminal/ssh

The UI problem with long-press context menu is I think sailfish bug where if the item is larger than viewport the context menu doesn't "move into view". I'll check it out and see if there's something that can be done for this case on the UI side.

First priority is fixing the crash of course. Do you know ~how long the message is? Just so I can know if it's length or maybe specific character related.

Thanks

moorchegue commented 5 years ago

That worked perfectly well, thanks!

Now that I'm able to get rid of these messages in case of a crash I tried a couple and found that shorter ECC key gets transferred normally. But the normal RSA 2048 bit key (its ascii representation to be precise) is crashing the app.

Here's an example:

almindor commented 5 years ago

Yes, I just reproduced the crash. It's an error from toxcore sadly, TOX_ERR_FRIEND_SEND_MESSAGE_TOO_LONG currently limited to 1372 bytes in size.

Seems toxcore itself has a limit on max size, I didn't realize this and just manually put this in the list. Will investigate actual max size and try to auto-split in the next release since that's the only thing I can do here. Sucks for PGP keys tho. I suggest you use file transfer for these.

NOTE: I wasn't able to reproduce the "can't see context menu" issue tho. Even if the msg was larger than viewport it scrolled down and popped up the context menu ok for me.

moorchegue commented 5 years ago

Well, yeah, it's not a big deal, as long as you know about it. File transfer works.

Re: UI, to clarify it's only invisible when long-tapping an unsent long text message. With sent messages of any size it works just fine. The device is Jolla C, Sailfish OS version 2.2.0.29 if that makes a difference.

moorchegue commented 5 years ago

Although it can be annoying when there's no file and you'd have to create it first (e.g. you're simply copy-pasting some text), that could be very annoying. Does toxcore provide any API to split-join messages? And if not would it be wrong conceptually to implement it outside of toxcore?

I just ran a couple of experiments with clients installed on my computer. qTox did split the text and sent it as 2 messages. And then i tried Toxic: it somehow managed to send the text as one whole message, and I received it in jTox intact as well. Maybe worth checking how they do it?

almindor commented 5 years ago

It seems they auto-join if the previous message is max sized. They mention that clients should auto-join on their end in the docs but there doesn't seem to be any particular distinction between a full-sized message singular followed by a separate message and a dual-split auto-join message.

So if you send something that's 1372 bytes long exactly followed by a separate message, I think it'll auto-join. Maybe they do some sort of time based auto-joining tho preventing this from triggering.

I'll investigate after the next release. Need to fix this error handling to stop just throwing/crashing first.

Created #69 to track the auto-joining.

almindor / harbour-jTox

jTox crashes trying to send a long text #68