Don't connect to Tor if it's already running
For some time now we've had a reliable way of shutting down the Tor process (the __OwningControllerProcess command line argument combined with the TAKEOWNERSHIP command), but TorPlugin#start() still assumes that Tor may already be running. This allows another app to bind the Tor control and SOCKS ports and collect confidential data from Briar (#578). It also allows two Briar instances running on the same device to try to communicate with the same Tor process, which prevents proper shutdown (#572).
This patch prevents the Tor plugin from starting unless it's able to start its own Tor process with the expected control and SOCKS ports. If two Briar instances are running on the same device, only one of them will be able to use Tor. The other should fail to start its Tor plugin and then function normally without Tor access, including normal shutdown.
Fixes#572, #578. Open another ticket if you want two Briar instances on the same device to have their own Tor processes. :-)
See merge request !272
Allow unsubscribing from shared blogs
Only personal blogs from non-contacts can be removed.
This also adds integration tests that check the conditions under which blogs can actually be removed.
Closes#579
See merge request !268
Prevent empty state messages from showing briefly
When we clear a list in `onPause()`, the proper behavior is that the empty state
message is shown, because the list is indeed empty.
However, we will reload the list content again in `onResume()`,
so the fix chosen in this MR is to force showing the progress bar
right after clearing the list.
Closes#576
See merge request !267
When we clear a list in onPause(), the proper behavior is that the empty state
message is shown, because the list is indeed empty.
However, we will reload the list content again in onResume(),
so the fix chosen in this commit is to force showing the progress bar
right after clearing the list.
Closes#576
This commit refactors the code for sharing forums,
so it can be used for sharing blogs as well.
It does not yet include code for responding to blog invitations.
Use Client Layer Events in ContactListFragment
This prevents trying to access the same group metadata in different groups.
Also, the conversation does not need to be reloaded once introduction messages arrive.
Closes#535
See merge request !254
The forum UI depended on sync layer events such as MessageStateChangedEvent.
Now, the forum client broadcasts its own high-level event (`ForumPostReceivedEvent`)
with the information the UI needs (`ForumPostHeader`).
Closes#310
This prevents trying to access the same group metadata in different groups.
Also, the conversation does not need to be reloaded once introduction messages arrive.
Closes#535
Micro Blogs UI
**Attention:** This MR includes several other commits which are supposed to end up in separate MRs. I suggest that you review **per commit**. Once the first two commits have green light, I can split out the other commits into other MRs. This way I don't have to work myself through a long rebase chain every time I make a change to the bottom MR.
This MR is full of commits that introduce features that we will not be using initially. The last commit implements the Micro Blogs UI on top of the framework the first commits establish and hides/disables all future features for now.
I suggest we merge this as is and clean things up later when we have a clearer idea what features we will be doing eventually.
Closes#436
See merge request !214
Make it clearer who will be introduced
Show contact names under avatars before sending introduction to make it clearer who will be introduced.
Closes#356
See merge request !242
