briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:17Zhttps://code.briarproject.org/briar/briar/-/issues/679Own personal blogs can be removed2018-06-12T11:32:17ZTorsten GroteOwn personal blogs can be removedThe `canBeRemoved()` method seems to return `true` for own personal blogs now. There should be a test for that to prevent this regression in the future.The `canBeRemoved()` method seems to return `true` for own personal blogs now. There should be a test for that to prevent this regression in the future.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/678Implement UX for viewing the membership of a private group2018-06-05T20:39:27ZakwizgranImplement UX for viewing the membership of a private groupDesign ticket is #657. Subtask of #undefined
![](https://code.briarproject.org/akwizgran/briar/uploads/970095a7bdb2bfb6b1684ffe82ea6a94/657_member_list.jpg)
Design ticket is #657. Subtask of #undefined
![](https://code.briarproject.org/akwizgran/briar/uploads/970095a7bdb2bfb6b1684ffe82ea6a94/657_member_list.jpg)
Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/677Unavailable menu items should be disabled rather than removed2018-06-05T20:39:27ZakwizgranUnavailable menu items should be disabled rather than removedPer the material design guidelines: https://material.google.com/components/menus.html#menus-menu-items
Two existing menu items are affected: make introduction and remove blog.Per the material design guidelines: https://material.google.com/components/menus.html#menus-menu-items
Two existing menu items are affected: make introduction and remove blog.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/676Keyboard isn't shown when forum text entry field gets focus2018-06-12T11:32:17ZakwizgranKeyboard isn't shown when forum text entry field gets focusWhen touching the compose or reply button in a forum, the text entry field appears and gets focus, but the keyboard isn't shown until the field is touched. The keyboard should be shown automatically.When touching the compose or reply button in a forum, the text entry field appears and gets focus, but the keyboard isn't shown until the field is touched. The keyboard should be shown automatically.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/675Incoming forum posts block the crypto executor2018-06-12T11:32:18ZakwizgranIncoming forum posts block the crypto executorSteps to reproduce:
* Create a forum with a large number of posts on device A
* Share the forum with device B
* Accept the invitation on device B
* Write private messages on device B while the forum posts are syncing
Expected result:
* ...Steps to reproduce:
* Create a forum with a large number of posts on device A
* Share the forum with device B
* Accept the invitation on device B
* Write private messages on device B while the forum posts are syncing
Expected result:
* Locally created messages appear in the private conversation immediately
Actual result:
* Locally created messages appear in the private conversation after a long delay
What I believe is happening is that all the CryptoExecutor threads are busy validating forum posts. Creating a private message involves submitting a task to the CryptoExecutor, and those tasks get stuck behind the forum validation tasks.
We could easily fix this for private message by moving creation off the CryptoExecutor, as creating a private message doesn't involve any long-running crypto operations, but the problem would still exist for forum posts, blog posts, etc.
A proper fix would involve limiting the number of messages the validation manager queues for validation. At present there's no limit - all messages that require validation are queued on the CryptoExecutor and then passed to the DbExecutor.
(This issue existed before the ValidationManager refactoring, but I didn't get round to reproducing it until now.)
Related to #511.Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/674Ending a transaction can throw an exception in a finally block2018-06-12T11:32:18ZakwizgranEnding a transaction can throw an exception in a finally blockWe use the following pattern to commit or roll back a transaction:
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
txn.setComplete();
} finally {
db.endTransaction(txn);
}
```
`DatabaseComponent#endTr...We use the following pattern to commit or roll back a transaction:
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
txn.setComplete();
} finally {
db.endTransaction(txn);
}
```
`DatabaseComponent#endTransaction()` can throw a `DbException`, and Android Studio warns about the potential for the exception to be thrown in a finally block.
We should move the exception-throwing code from `endTransaction()` into a new `commitTransaction()` method, which replaces `Transaction#setComplete()` and is called inside the try block. The new contract of `endTransaction()` should be to abort the transaction if it has not already been committed, and release the database lock in either case.
```
Transaction txn = db.startTransaction();
try {
db.doSomething(txn);
db.commitTransaction(txn);
} finally {
db.endTransaction(txn);
}
```Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/673PrivateGroupManager facade2018-06-12T11:32:18ZakwizgranPrivateGroupManager facadeCreate a PrivateGroupManager interface in briar-api, with a stub implementation in briar-core, to allow development of the UI. The interface can be based on the existing ForumManager, with supporting classes for message headers, etc, as ...Create a PrivateGroupManager interface in briar-api, with a stub implementation in briar-core, to allow development of the UI. The interface can be based on the existing ForumManager, with supporting classes for message headers, etc, as required.
Subtask of #127.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/672Implement UX for dissolving a group2018-06-05T20:39:27ZakwizgranImplement UX for dissolving a groupSubtask of #127. Design ticket is #651.
![](https://code.briarproject.org/akwizgran/briar/uploads/602c4f6ade32ea02f0ff2b81942dec88/651_dissolve_group.jpg)Subtask of #127. Design ticket is #651.
![](https://code.briarproject.org/akwizgran/briar/uploads/602c4f6ade32ea02f0ff2b81942dec88/651_dissolve_group.jpg)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/671Implement UX for leaving a group2018-06-05T20:39:27ZakwizgranImplement UX for leaving a groupSubtask of #127. Design ticket is #undefined
![](https://code.briarproject.org/akwizgran/briar/uploads/ba733def3eec688975d93d959839124f/652_leave_group.jpg)Subtask of #127. Design ticket is #undefined
![](https://code.briarproject.org/akwizgran/briar/uploads/ba733def3eec688975d93d959839124f/652_leave_group.jpg)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/670Uncaught exceptions do not print a stack trace in IntroductionIntegrationTest2018-06-12T11:32:18ZSantiago Torres-AriasUncaught exceptions do not print a stack trace in IntroductionIntegrationTestErrors and uncaught exceptions do not print a stack trace unless a try/catch block is added for NPE. This is a followup for the discussion in !237Errors and uncaught exceptions do not print a stack trace unless a try/catch block is added for NPE. This is a followup for the discussion in !237Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/669Integration tests need to know the client ID of MessageStateChangedEvents2018-06-12T11:32:18ZakwizgranIntegration tests need to know the client ID of MessageStateChangedEventsRecent refactoring of the validation manager removed the client ID from MessageStateChangedEvents, because these events are only used by tests and a lot of code in the validation manager and DB existed just to attach client IDs to these ...Recent refactoring of the validation manager removed the client ID from MessageStateChangedEvents, because these events are only used by tests and a lot of code in the validation manager and DB existed just to attach client IDs to these events. This has made the tests fail unpredictably.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/668Invitation messages can be displayed in the wrong order2018-01-11T16:18:53ZakwizgranInvitation messages can be displayed in the wrong orderWhen devices have slightly inaccurate clocks, an invitation response can have an earlier timestamp than the corresponding request. This causes the messages to be displayed in the wrong order in both parties' conversations, so the invitat...When devices have slightly inaccurate clocks, an invitation response can have an earlier timestamp than the corresponding request. This causes the messages to be displayed in the wrong order in both parties' conversations, so the invitation seems to have been accepted before it was sent.
![device-2016-09-21-155626](/uploads/4f1fe82a8c962c4b103339b5cc802124/device-2016-09-21-155626.png)
One possible solution is for the sender to set the timestamp of the response to max(timestamp of request + 1, current time) when creating the response.
Another possible solution is for the recipient to set the metadata timestamp of the response to max(timestamp of request + 1, timestamp of response) in the delivery hook. This could backfire if the message timestamp is used in some places and the metadata timestamp is used in others.akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/666Transport icons overlap navigation items2018-11-14T13:52:07ZakwizgranTransport icons overlap navigation itemsThe screenshot shows a Galaxy Nexus with the screen rotated to portrait mode:
![device-2016-09-20-170847](/uploads/455383817175015faf77b25098a95c20/device-2016-09-20-170847.png)The screenshot shows a Galaxy Nexus with the screen rotated to portrait mode:
![device-2016-09-20-170847](/uploads/455383817175015faf77b25098a95c20/device-2016-09-20-170847.png)Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/665Potential NPE in AndroidExecutorImpl2018-06-12T11:32:18ZakwizgranPotential NPE in AndroidExecutorImplIf two threads call `AndroidExecutor#runOnBackgroundThread()` in quick succession, the first call will initialise the Handler for the background thread and wait for it to be initialised before using it. The second call will assume the Ha...If two threads call `AndroidExecutor#runOnBackgroundThread()` in quick succession, the first call will initialise the Handler for the background thread and wait for it to be initialised before using it. The second call will assume the Handler has been initialised and try to use it immediately, potentially throwing an NPE.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/664Don't throw an exception if a client has no delivery hook2018-06-12T11:32:18ZakwizgranDon't throw an exception if a client has no delivery hookThe validation manager throws an exception if it tries to deliver a message to a client and the client hasn't registered a delivery hook. The transport property manager doesn't register a delivery hook, so apparently it's possible to wri...The validation manager throws an exception if it tries to deliver a message to a client and the client hasn't registered a delivery hook. The transport property manager doesn't register a delivery hook, so apparently it's possible to write a client that doesn't need one, and the validation manager should just mark the message a delivered.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/663Implement UX for displaying message threads in private groups2018-06-12T11:32:18ZakwizgranImplement UX for displaying message threads in private groupsDepends on #650. Subtask of #127.
May depend on fixes for #443, #525, #526, #527, #552.Depends on #650. Subtask of #127.
May depend on fixes for #443, #525, #526, #527, #552.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/662Implement UX for composing and replying to private group messages2018-06-12T11:32:18ZakwizgranImplement UX for composing and replying to private group messagesDepends on #649. Subtask of #127.Depends on #649. Subtask of #127.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/661Implement UX for creating a private group2018-06-12T11:32:18ZakwizgranImplement UX for creating a private groupDepends on #648. Subtask of #127.
![](https://code.briarproject.org/akwizgran/briar/uploads/ab2eb815a24ade00564409afcf4e8f19/648_A_flow.jpg)
Depends on #648. Subtask of #127.
![](https://code.briarproject.org/akwizgran/briar/uploads/ab2eb815a24ade00564409afcf4e8f19/648_A_flow.jpg)
Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/660Implement UX for the list of private groups2018-06-12T11:32:18ZakwizgranImplement UX for the list of private groupsDepends on #656. Subtask of #127.
![list of private groups](https://code.briarproject.org/akwizgran/briar/uploads/5538a5b7a515228da908afe57367038c/656_pg_list.jpg)Depends on #656. Subtask of #127.
![list of private groups](https://code.briarproject.org/akwizgran/briar/uploads/5538a5b7a515228da908afe57367038c/656_pg_list.jpg)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/659Protocol for private group invitations2018-06-12T11:32:18ZakwizgranProtocol for private group invitationsThis could be similar to the blog and forum invitation protocols, but there's an opportunity to make it simpler, as only the creator of the group can send invitations. When a member has been added or removed, the creator should send an a...This could be similar to the blog and forum invitation protocols, but there's an opportunity to make it simpler, as only the creator of the group can send invitations. When a member has been added or removed, the creator should send an announcement to the group (see #658).
Related to #456. Subtask of #127.Milestone Eakwizgranakwizgran