Because we do a number of async checks before allowing the real send to
begin, on a slow matchine or when doing a lot of work (like receiving a
lot of messages) there can be a noticeable delay between hitting Enter
and the clearing of the text in the message box. In fact, newly-typed
text can be added to the previous message if the delay is long enough.
This prevents any interaction with the message box until the send has
either been prevented or has started.
FREEBIE
Discovered a user log where expiring message checks were happening
constantly. This ensures that a very large timeout doesn't roll over
into immediate callbacks.
FREEBIE
isVerified and isUntrusted both went to the protocol layer, but were not
prepared for rejected promises resulting from missing records. This
prevented send in large groups where there has never been a message
exchanged with one of the members.
FREEBIE
Notable changes:
Application loading screen
- We now properly process read receipts, delivery receipts and other
types of sync messages before dismissing the screen.
Fix: Properly report decryption errors when they happen
Fix: Slow down expiring message processing, especially on startup (may
result in lower CPU/memory usage)
I believe this to be the reason behind some of the high resource usage
on startup. If a lot of read receipts come in for disappearing messages,
this method can be called many, many times very quickly.
FREEBIE
Notable changes:
Verified contacts
- Ability to verify a contact's safety number, same for group's
members via the 'Show members' screen
- Check mark next to verified contacts, and next to
100%-verified groups
- Synchronization of verification decisions across devices
- Banner and confirmation on send when previously-verified safety
number changes
- Confirmation on send if safety number has changed very recently
- Updated message detail screen when a message fails due to a safety
number change
Delete individual message from message detail screen
Clearer error text when a message to a group partially fails
Icons for in-conversation timer change and key change notifications
We now drop duplicate messages when we receive them
A number of reliability fixes:
- New 'unprocessed' cache for messages not yet fully processed,
attempted re-process on startup
- Protections against 'wedged' conversations, which won't receive or
send messages until restart
- Better resilience to errors throughout the codebase
Application loading screen until server backlog is fully processed
- Shows messages processed so far
- Prevents large numbers of notifications from firing on application
startup
Conversation loading screen
Unloading of conversations and old messages due to inactivity to reduce
memory usage
Potential fix for "Too many message keys for chain" (caused after
desktop is offline for long time)
FREEBIE
Not sure exactly how to think about Chrome app lifetimes, so we're
being conservative. We only show the full-application loading screen
once, on first display of the inbox.
FREEBIE
