On a recent trip through a CPU profile taken while Signal Desktop
churned through a large backlog of messages, it was clear that
console.log was a major source of time spent, primarily the sort
operation required after every new entry is added to the Backbone
collection. So, three different techniques to combat this:
1) Reduce the maximum number of entries in the collection from 5k to 2k
2) No more logging of add/update/remove queue in MessageReceiver
3) No more log entries in Message.handleDataMessage main codepath
FREEBIE
When processing a contact sync with embedded identity key verification info, we
were running overlapping async fetch/save operations on the same conversation
model, causing a race that tends to clobber updates to the contact info.
In this change we extend the application-level contact info handler to block on
a subsequent call to the verification handler, which effectively serializes the
fetch/save calls, and relieves the need for the message receiver to trigger a
seperate event concerning the verification info on contact sync messages.
Fixes#1408
// FREEBIE
* Add support for backup and restore
This first pass works for all stores except messages, pending some scaling
improvements.
// FREEBIE
* Import of messages and attachments
Properly sanitize filenames. Logging information that will help with
debugging but won't threaten privacy (no contact or group names),
where the on-disk directories have this information to make things
human-readable
FREEBIE
* First fully operational single-action export and import!
FREEBIE
* Add migration export flow
A banner alert leads to a blocking ui for the migration. We close the socket and
wait for incoming messages to drain before starting the export.
FREEBIE
* A number of updates for the export flow
1. We don't immediately pop the directory selection dialog box, instead
showing an explicit 'choose directory' button after explaining what is
about to happen
2. We show a 'submit debug log' button on most steps of the process
3. We handle export errors and encourage the user to double-check their
filesystem then submit their log
4. We are resilient to restarts during the process
5. We handle the user cancelling out of the directory selection dialog
differently from other errors.
6. The export process is now serialized: non-messages, then messages.
7. After successful export, show where the data is on disk
FREEBUE
* Put migration behind a flag
FREEBIE
* Shut down websocket before proceeding with export
FREEBIE
* Add MigrationView to test/index.html to fix test
FREEBIE
* Remove 'Submit Debug Log' button when the export process is complete
FREEBIE
* Create a 'Signal Export' directory below user-chosen dir
This cleans things up a bit so we don't litter the user's target
directory with lots of stuff.
FREEBIE
* Clarify MessageReceiver.drain() method comments
FREEBIE
* A couple updates for clarity - event names, else handling
Also the removal of wait(), which wasn't used anywhere.
FREEBIE
* A number of wording updates for the export flow
FREEBIE
* Export complete: put dir on its own line, make text selectable
FREEBIE
There's really no reason to retry encryption errors again if they've
already been made user-visible in a conversation.
Also, refactor e->error in background.js onError(), since both e and ev
in this method made it too easy to make a mistake.
These were failing because ByteBuffers from the protobufs need to be converted
to ArrayBuffers. Fixed by useing the existing handler in MessageReceiver to
process verified messages from contact sync messages and dispatch them as their
own events, reducing some complexity on the application side.
// FREEBIE
Just log em for debugging. Also update the error messge thrown when we get a
content message with no supported properties. It may be empty or may just have
an unrecognized field.
// FREEBIE
This adds a new method to message sender for sending verification sync messages
and a new event to message receiver representing incoming verification sync
messages. Currently the event handler just logs the message.
// FREEBIE
Previously we only expected these errors to occur when decrypting prekey
messages, so we need to add handling for them in the case of a normal message.
// FREEBIE
There may come a day when we may need to change this url from the server
side. On that day, clients should continue to operate normally. The
service should be able to change attachment server locations without
requiring a client update.
// FREEBIE
