When typing in an existing phone number into the search, clicking on it even
though there exists an existing contact will reinitialize that contact’s
database entry. This reinitialization clears that contact’s conversation’s name,
unread count, etc.
This change ensures we always reuse existing conversations using
`ConversationController.getOrCreateAndWait` when starting new conversations in
the search view.
When searching for an existing conversation using a phone number, it’s possible
to click on ‘Start conversation…’ and have that new dummy entry overwrite the
existing conversation.
This change ensures we are always showing a dummy conversation model that is not
part of the conversation collection. Adding it is always idempotent as it goes
through `getOrCreateAndWait`.
Class: `ConversationController`.
This function should not be used in application code as it creates potentially
invalid `Conversation` instances in our global conversation collection. We keep
making it available for testing purposes.
- We first show a localized loading message.
- If initialization takes longer than a certain threshold, we show a different
‘optimization’ message.
- If initialization is below the threshold the message change is canceled right
before the regular loading screen.
Let’s make it clear that this is where we initialize our namespaces to avoid
proliferation of various initialization points now that we support CommonJS.
In order to avoid incurring long startup times, we migrate message schema (data) in the background using `window.requestIdleCallback` API. The migration moves attachment data from IndexedDB to disk and reduces load on our database which may cause data loss (#1589).
On my development profile, this migration reduced the IndexedDB directory from 33.4MB to 4.7MB.
Daniel Gasienica
AJ Jordan
Scott Nonnenberg