Clicking on a key conflict message opens the message detail view,
which displays the contact(s) in this conversation. If the message
contains a key conflict with any of these contacts, a button is
displayed which attempts to resolve that conflict and any other
conflicts in the conversation that are related to that contact.
We'd like to live in a world where we can retry all the pending
conflicts in a conversation as a batch, which means we don't want to
wipe the identity key before processing each message. Thus, remove that
step from these handlers and encapsulate in a method on the conversation
model.
Ensure that both tryAgain functions return promises, allowing the
application to take appropriate action in the result of success or
failure. This lets us remove all dependency from libtextsecure on
app-level constructs like message objects/ids and the `extenion.trigger`
function.
Corresponding frontend changes to follow in another commit.
1. Return the value returned by the registered function, to expose the
underlying promise to the caller.
2. Stop accepting extra arguments to the replay function. The caller
should be able to do what they want with the returned promise instead.
3. Add a timestamp argument to the outgoing case, needed to re-try
sending a message.
Rather than opening the inbox in its own window, let it appear as a
browser action popup by default, but allow promotion to its own window
if requested.
Let libaxolotl throw a generic error instead of a replayable error, and
add an helper function in libtextsecure's axolotl_wrapper to catch and
convert from the generic error to the replayable one. This allows the
ReplayableError to remain a libtextsecure-level concept only.
Somewhat unrelatedly, but nearby, fix some whitespace and add missing
semicolon.
`emoji.init_colons` creates and populates `emoji.map.colons`, a global
map from common names to emoji code points. It's safe to call
repeatedly, but unecessary.
Now with actual malloc/free implementations. Had to drop back to -O1
optimization because the ed25519 signature test broke with -O2. :(
Closes#153
The toolchain install and build process, for reference:
```
wget https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz
tar xvfz emsdk-portable.tar.gz
cd emsdk-portable
./emsdk update
./emsdk install latest
./emsdk activate latest
source ./emsdk_env.sh
cd ../TextSecure-Browser
grunt build
```
I had some trouble with the registration..
Quickly checked TextSecure Server API and found the problems:
number has to be valid PSTN. (Including regionCode, precisely what validateNumber() returns)
verificationCode has to be all numbers, no dashes or spaces
Closes#193
Update unreadCounts per-conversation on incoming messages. Render unread
conversations with font-weigh: bold in the inbox view.
To ensure that the inbox and conversation views remain in sync, the
background page now ensures that the same models objects are used for
both views.
Turns out we can get ABNORMAL_CODE (1006) for disconnects where (for
instance) we pause the background page too long. However, in these cases
there is no preceeding ErrorEvent. In contrast, when we have bad
authentication credentials, there is an ErrorEvent. Thus, this change
ensures that we only reconnect if there was no Error.
Templatize the inbox view and use the same pattern for in-window view
switching as is now used with the conversation/message detail views.
This means doing more with markup and less jquery manipulation of
individual subelements of the inbox view.
Closes#173
Previously, in the event of a failed websocket auth, we would attempt to
reconnect once a second ad infinitum. This changeset ensures that we
only reconnect automatically if the socket closed 'normally' as
indicated by the code on the socket's CloseEvent. Otherwise, show a
'Websocket closed' error on the inbox view.
Ideally we would show a more contextual error (ie, 'Unauthorized'), but
unfortunately the actual server response code is not available to our
code. It can be observed in the console output from the background page,
but programmatically, we only receive the WebSocket CloseEvent codes
listed here:
https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes
The websocket error message is displayed by a normally-hidden but ever
present socket status element. Clicking this element will immediately
refresh the background page, which will try again to open the websocket
connection.
When first intalling, users will no longer be presented with the option
to register as a standalone client.
For developer convenience, the standalone form can still be found at
chrome-extension://.../register.html
Closes#159
