app: fix reply ordering

[redshiftzero]

Description

Fixes #653.

supersedes #818

Test Plan

follow STR in 653

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, packaging logic (e.g., the AppArmor profile) may need to be updated. Please check as applicable:

• I have submitted a separate PR to the packaging repo
• No update to the packaging logic (e.g., AppArmor profile) is required for these changes
• I don't know and would appreciate guidance

[sssoleileraaa]

nice! this fixes the issue

[sssoleileraaa]

lgtm and works as described...

I'm just trying to understand what the problem was with the reordering issue and why it only came up when a reply failed. This is what seemed to be happening before your change:

https://user-images.githubusercontent.com/4522213/75492917-9f787380-596d-11ea-9ad8-1b54fadb1d74.gif

in the video you can see i start of with 4 replies that go from pending to successful and then the 5th reply fails:

"1" successful reply   widget_index=1 file_counter=1
"2" successful reply   widget_index=2 file_counter=2
"3" successful reply   widget_index=3 file_counter=3
"4" successful reply   widget_index=4 file_counter=4
"5" failed reply       widget_index=5 file_counter=4 timestamp 1

then i sent another reply "6" after the failed reply "5":

"1" successful reply   widget_index=1 file_counter=1
"2" successful reply   widget_index=2 file_counter=2
"3" successful reply   widget_index=3 file_counter=3
"4" successful reply   widget_index=4 file_counter=4
"5" failed reply       widget_index=5 file_counter=4 timestamp 1
"6" pending reply      widget_index=6 file_counter=4 timestamp 2

then the failed reply "5" succeeds:

"1" successful reply   widget_index=1 file_counter=1
"2" successful reply   widget_index=2 file_counter=2
"3" successful reply   widget_index=3 file_counter=3
"4" successful reply   widget_index=4 file_counter=4
"5" successful reply   widget_index=5 file_counter=4
"6" pending reply      widget_index=6 file_counter=4 timestamp 2

then the pending reply "6" fails:

"1" successful reply   widget_index=1 file_counter=1
"2" successful reply   widget_index=2 file_counter=2
"3" successful reply   widget_index=3 file_counter=3
"6" failed reply       widget_index=4 file_counter=4 timestamp 2
"4" successful reply   widget_index=5 file_counter=4
"5" successful reply   widget_index=6 file_counter=4

then i restart the client and everything is in order:

"1" successful reply   widget_index=1 file_counter=1
"2" successful reply   widget_index=2 file_counter=2
"3" successful reply   widget_index=3 file_counter=3
"4" successful reply   widget_index=4 file_counter=4
"5" successful reply   widget_index=5 file_counter=5
"6" successful reply   widget_index=6 file_counter=6

[sssoleileraaa]

helpful comment ❤️

i think we should chat about followup issues regarding speech bubbles being drawn on top of each other and rare but sometimes missing replies

[sssoleileraaa]

I think this should probably be a follow-up issue, but i'm still sometimes seeing multiple replies being drawn on top of each other after a failed reply. Also, I saw a reply go missing until i restarted the client. These are issues that don't seem to happen regularly, and since this PR fixes the reproducible error I think we could go ahead with a merge and track the other issues separately.

@redshiftzero what do you think?

[redshiftzero]

OK I'm on board with that, I don't see how this could cause bubbles to appear on top of each other so I think if you're seeing overlain message bubbles then there's another issue on master. Regarding your example above, it's possible the reply is showing as failed incorrectly, since you close the client and restart and then it shows as succeeded (the behavior in #820 might be a cause, honestly not sure yet). Let's:

1. Merge this
2. See if we can repro the message bubble reappearing and fix (we can do this too during QA)
3. Comb through and try to shake out any other reply ordering issues the rest of this week and during QA