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
Model operations are vulnerable to exceptions thrown by event handlers.
Because this can interrupt really important data operations, it's better
to let the operation continue and log the error. In all likelihood it's
a view-related problem, and that shouldn't cause any data operation to
fail.
FREEBIE
