briar issueshttps://code.briarproject.org/groups/briar/-/issues2017-12-18T07:40:37Zhttps://code.briarproject.org/briar/briar/-/issues/742Use unique request IDs across the app2017-12-18T07:40:37ZakwizgranUse unique request IDs across the app@ernir came up with a nice solution for this: a static method that returns an incrementing counter.
```
private final static int REQUEST_INVITE = SomeUtil.getUniqueRequestId();
```@ernir came up with a nice solution for this: a static method that returns an incrementing counter.
```
private final static int REQUEST_INVITE = SomeUtil.getUniqueRequestId();
```Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/741Move events into their respective packages2017-12-18T07:40:37ZakwizgranMove events into their respective packagesAll events are currently in the package `org.briarproject.api.event`. Events that are specific to a given package should be moved into the package that uses them.
Sub-task of #136All events are currently in the package `org.briarproject.api.event`. Events that are specific to a given package should be moved into the package that uses them.
Sub-task of #136Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/738Older devices show overflow icon on some screens but not others2017-12-18T07:40:37ZakwizgranOlder devices show overflow icon on some screens but not othersOn the Sony Xperia Tipo (Android 4.0.4), which has a hardware menu button, the action bar overflow icon is shown on some screens but not others. For example, it's shown in the private conversation, but not in private groups. This should ...On the Sony Xperia Tipo (Android 4.0.4), which has a hardware menu button, the action bar overflow icon is shown on some screens but not others. For example, it's shown in the private conversation, but not in private groups. This should be consistent across the app.
In screens where it's shown, the menu can be opened by pressing either the overflow icon or the hardware button.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/731Open BDF Lists and Dictionary throw IllegalStateException2017-12-18T07:40:38ZTorsten GroteOpen BDF Lists and Dictionary throw IllegalStateExceptionThese tests should not fail:
```java
@Test(expected = FormatException.class)
public void testOpenList() throws Exception {
// A list that is not closed
String list = "60";
setContents(list);
r.readList();
}
@Test(expected = ...These tests should not fail:
```java
@Test(expected = FormatException.class)
public void testOpenList() throws Exception {
// A list that is not closed
String list = "60";
setContents(list);
r.readList();
}
@Test(expected = FormatException.class)
public void testOpenDictionary() throws Exception {
// A dictionary that is not closed
String dicts = "70" + "41" + "03" + "666F6F";
setContents(dicts);
r.readDictionary();
}
```Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/727Refactor integration tests2017-12-18T07:40:38ZakwizgranRefactor integration testsSome of the code for delivering messages could be factored out of integration tests into a common superclass or utility class. Some tests create more component instances than they need.Some of the code for delivering messages could be factored out of integration tests into a common superclass or utility class. Some tests create more component instances than they need.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/724Unit tests for ClientHelperImpl2017-12-18T07:40:38ZakwizgranUnit tests for ClientHelperImplMilestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/723Unit tests for ContactManagerImpl2017-12-18T07:40:38ZakwizgranUnit tests for ContactManagerImplMilestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/720IllegalStateException: CameraView.surfaceCreatedUi2017-12-18T07:40:39ZTorsten GroteIllegalStateException: CameraView.surfaceCreatedUiWhen trying to a contact, I managed to cause a crash:
```
10-26 14:24:24.354 I/KeyAgreementTransport: Closing connection
10-26 14:24:24.534 W/KeyAgreementTaskImpl: org.briarproject.keyagreement.AbortException: java.net.SocketTimeoutExcep...When trying to a contact, I managed to cause a crash:
```
10-26 14:24:24.354 I/KeyAgreementTransport: Closing connection
10-26 14:24:24.534 W/KeyAgreementTaskImpl: org.briarproject.keyagreement.AbortException: java.net.SocketTimeoutException
org.briarproject.keyagreement.AbortException: java.net.SocketTimeoutException
at org.briarproject.keyagreement.KeyAgreementTransport.readHeader(KeyAgreementTransport.java:117)
at org.briarproject.keyagreement.KeyAgreementTransport.readRecord(KeyAgreementTransport.java:97)
at org.briarproject.keyagreement.KeyAgreementTransport.receiveKey(KeyAgreementTransport.java:54)
at org.briarproject.keyagreement.KeyAgreementProtocol.receiveKey(KeyAgreementProtocol.java:115)
at org.briarproject.keyagreement.KeyAgreementProtocol.perform(KeyAgreementProtocol.java:90)
at org.briarproject.keyagreement.KeyAgreementTaskImpl.run(KeyAgreementTaskImpl.java:102)
Caused by: java.net.SocketTimeoutException
at java.net.PlainSocketImpl.read(PlainSocketImpl.java:492)
at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:241)
at org.briarproject.keyagreement.KeyAgreementTransport.readData(KeyAgreementTransport.java:125)
at org.briarproject.keyagreement.KeyAgreementTransport.readHeader(KeyAgreementTransport.java:115)
at org.briarproject.keyagreement.KeyAgreementTransport.readRecord(KeyAgreementTransport.java:97)
at org.briarproject.keyagreement.KeyAgreementTransport.receiveKey(KeyAgreementTransport.java:54)
at org.briarproject.keyagreement.KeyAgreementProtocol.receiveKey(KeyAgreementProtocol.java:115)
at org.briarproject.keyagreement.KeyAgreementProtocol.perform(KeyAgreementProtocol.java:90)
at org.briarproject.keyagreement.KeyAgreementTaskImpl.run(KeyAgreementTaskImpl.java:102)
10-26 14:24:24.564 E/CameraService: setPreviewCallbackFlag(7) (pid 29436)
10-26 14:24:24.644 I/DroidtoothPlugin: Connecting to key agreement UUID 5876756b-c0fe-3967-bc15-972d828bd7e4
10-26 14:24:24.644 I/DroidtoothPlugin: Connecting to 58:[scrubbed]:C4
10-26 14:24:24.644 I/DroidtoothPlugin: Failed to connect to 58:[scrubbed]:C4
10-26 14:24:24.705 I/KeyAgreementConnector: Stopping BQP listeners
10-26 14:24:24.705 I/KeyAgreementConnector: Starting BQP listeners
10-26 14:24:24.705 I/DroidtoothPlugin: Key agreement UUID 19b28b8f-5b4b-357e-9e84-e2b1a25723d6
10-26 14:24:24.735 I/CameraView: Surface created
10-26 14:24:24.735 W/dalvikvm: threadid=1: thread exiting with uncaught exception (group=0x414b7438)
10-26 14:24:24.735 E/ACRA: ACRA caught a IllegalStateException for org.briarproject
java.lang.IllegalStateException
at org.briarproject.android.view.CameraView.surfaceCreatedUi(CameraView.java:298)
at org.briarproject.android.view.CameraView.access$000(CameraView.java:36)
at org.briarproject.android.view.CameraView$1.run(CameraView.java:290)
at android.os.Handler.handleCallback(Handler.java:615)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4904)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:790)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:557)
at dalvik.system.NativeStart.main(Native Method)
```Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/719Reproduce issues with LAYER_TYPE_NONE2017-12-18T07:40:39ZakwizgranReproduce issues with LAYER_TYPE_NONEReproduce the performance and rendering issues that were seen on the Galaxy Ace 2 when using long EmojiTextViews with LAYER_TYPE_NONE.Reproduce the performance and rendering issues that were seen on the Galaxy Ace 2 when using long EmojiTextViews with LAYER_TYPE_NONE.Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/714Potential crashes when calling getActivity() asynchronously2017-12-18T07:40:39ZakwizgranPotential crashes when calling getActivity() asynchronouslyFragments sometimes call getActivity() asynchronously. !341 should ensure that we never call getActivity() in situations where the activity has been destroyed, but it's still possible that we're calling it in situations where the fragmen...Fragments sometimes call getActivity() asynchronously. !341 should ensure that we never call getActivity() in situations where the activity has been destroyed, but it's still possible that we're calling it in situations where the fragment has been detached from the (still existing) activity, and getActivity() therefore returns null.Milestone Fhttps://code.briarproject.org/briar/briar/-/issues/710ConversationActivity uses uninitialised field as format string argument2017-12-18T07:40:39ZakwizgranConversationActivity uses uninitialised field as format string argumentConversationActivity's contactName field is used as a format string argument in event handlers that may be called before the field has been initialised. This could cause an NPE in the string formatting code.ConversationActivity's contactName field is used as a format string argument in event handlers that may be called before the field has been initialised. This could cause an NPE in the string formatting code.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/705Race conditions when updating UI from events2018-11-06T15:47:33ZakwizgranRace conditions when updating UI from eventsWhen a UI element can be updated either by loading data from the DB or in response to an event, there's the potential for a race condition that results in stale data being shown:
* DB task loads data from the DB
* DB is updated, event i...When a UI element can be updated either by loading data from the DB or in response to an event, there's the potential for a race condition that results in stale data being shown:
* DB task loads data from the DB
* DB is updated, event is broadcast
* Event handler posts an update to the UI thread
* DB task posts an update to the UI thread, overwriting changes from event
There are a *lot* of race conditions like this in the existing codebase when adding, removing, or updating list items.
The race can be avoided by starting a new DB task from the event handler: the DB executor is single-threaded, so the new task is guaranteed to access the DB and post its update to the UI thread after any existing tasks. But this is inefficient - where possible, it would be nice if we could use the information in the event to update the UI without hitting the DB.Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/701Refactor message serialisation code out of briar-api2018-06-12T11:32:17ZakwizgranRefactor message serialisation code out of briar-apiThe SharingMessage, BlogSharingMessage and ForumSharingMessage classes in briar-api contain a mixture of interface declaration, serialisation code and factory code. Most of this code should be refactored into briar-core.The SharingMessage, BlogSharingMessage and ForumSharingMessage classes in briar-api contain a mixture of interface declaration, serialisation code and factory code. Most of this code should be refactored into briar-core.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/700Update blog backend to match current usage2018-01-28T11:30:28ZakwizgranUpdate blog backend to match current usageThe blog backend supports some features we're not using:
* Multiple blogs per author
* Titles for blogs and posts
* Descriptions for blogs
On the other hand, the backend doesn't provide any support for distinguishing between imported RS...The blog backend supports some features we're not using:
* Multiple blogs per author
* Titles for blogs and posts
* Descriptions for blogs
On the other hand, the backend doesn't provide any support for distinguishing between imported RSS posts and native Briar posts.
We have to balance two concerns: keeping the implementation flexible so that we can add new features, and keeping the implementation simple so it's easier to maintain and audit. Forward compatibility isn't a major concern: we're going to be breaking compatibility in many other ways over the coming months, so keeping the blog protocol forward compatible while everything else breaks won't achieve anything.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/698Remove support for anonymous forum posts2018-06-12T11:32:17ZakwizgranRemove support for anonymous forum postsThe UI no longer supports writing anonymous forum posts - we should also remove support from the backend.The UI no longer supports writing anonymous forum posts - we should also remove support from the backend.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/697Include commit ID in crash reports and feedback2018-06-12T11:32:17ZakwizgranInclude commit ID in crash reports and feedback1. Include the commit ID in BuildConfig as follows: http://stackoverflow.com/a/35041457
2. Get the commit ID from BuildConfig at runtime and include it in the custom data provided to ACRA1. Include the commit ID in BuildConfig as follows: http://stackoverflow.com/a/35041457
2. Get the commit ID from BuildConfig at runtime and include it in the custom data provided to ACRAMilestone FTorsten 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/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/646UX for groups that are synced with contacts who are all offline2018-06-12T11:32:19ZakwizgranUX for groups that are synced with contacts who are all offlineDecide how to display blogs, forums and private groups that are synced with contacts who are all offline (thus no messages will be sent or received until one of those contacts comes online).
"Do nothing" may be an acceptable solution.Decide how to display blogs, forums and private groups that are synced with contacts who are all offline (thus no messages will be sent or received until one of those contacts comes online).
"Do nothing" may be an acceptable solution.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/643Allow messages to be deleted in the delivery hook2018-06-12T11:32:19ZakwizgranAllow messages to be deleted in the delivery hookIf a client deletes a message in the delivery hook, the validation manager treats the message as invalid. Clients may want to delete messages they've finished handlng without having them invalidated, so we should provide some other way f...If a client deletes a message in the delivery hook, the validation manager treats the message as invalid. Clients may want to delete messages they've finished handlng without having them invalidated, so we should provide some other way for the delivery hook to signal that a message is invalid, such as throwing an InvalidMessageException.Milestone FTorsten GroteTorsten Grote