briar issueshttps://code.briarproject.org/briar/briar/-/issues2017-12-18T07:40:38Zhttps://code.briarproject.org/briar/briar/-/issues/726Layout for private group join message isn't i18n-friendly2017-12-18T07:40:38ZakwizgranLayout for private group join message isn't i18n-friendlyThe layout for private group join messages combines an AuthorView with a TextView to form a sentence. This won't work for languages where the subject doesn't come at the start of the sentence.
Review the layout so that the AuthorView is...The layout for private group join messages combines an AuthorView with a TextView to form a sentence. This won't work for languages where the subject doesn't come at the start of the sentence.
Review the layout so that the AuthorView is separate from the sentence.Milestone Ehttps://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/722Implement UX design for inviting new members to a group2017-12-18T07:40:39ZTorsten GroteImplement UX design for inviting new members to a groupSubticket of #127. Design discussion in #653
![](https://code.briarproject.org/akwizgran/briar/uploads/47e136beab2fa3d22dbac8d2943fe101/653_add_member.jpg)Subticket of #127. Design discussion in #653
![](https://code.briarproject.org/akwizgran/briar/uploads/47e136beab2fa3d22dbac8d2943fe101/653_add_member.jpg)Milestone ETorsten 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/718Creating a group without having contacts can cause crash2017-12-18T07:40:39ZTorsten GroteCreating a group without having contacts can cause crashCurrently, it is possible to create a private group without having contacts, but the group creation code assumes that you have at least one contact. If you try to create a group without having contacts, you land in a strange UI state and...Currently, it is possible to create a private group without having contacts, but the group creation code assumes that you have at least one contact. If you try to create a group without having contacts, you land in a strange UI state and when you press the back button, briar crashes.
I see two simple solutions for this:
1. Only allow creating groups when the user has at least one contact (requires a different empty state message)
2. Allow for creating groups without having contacts.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/715Long posts aren't rendered2017-12-18T07:40:39ZakwizgranLong posts aren't renderedOn the Galaxy Nexus, long blog posts from an RSS feed aren't rendered. The following warning is logged:
```
10-20 15:37:47.647 18342-18342/org.briarproject W/View: View too large to fit into drawing cache, needs 4553568 bytes, only 368...On the Galaxy Nexus, long blog posts from an RSS feed aren't rendered. The following warning is logged:
```
10-20 15:37:47.647 18342-18342/org.briarproject W/View: View too large to fit into drawing cache, needs 4553568 bytes, only 3686400 available
```
Shorter posts from the same feed render without problems. Looks like this might be caused by software rendering. At least we have a device that prints useful warnings about this. :-)Milestone ETorsten GroteTorsten Grotehttps://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/713Don't always scroll to bottom of conversation when a message arrives2019-06-17T10:10:29ZakwizgranDon't always scroll to bottom of conversation when a message arrivesIf the conversation is already scrolled to the bottom, scroll to the bottom after adding the new item so it becomes visible. Otherwise don't scroll, as the user may be manually scrolling back in the conversation to look for something.If the conversation is already scrolled to the bottom, scroll to the bottom after adding the new item so it becomes visible. Otherwise don't scroll, as the user may be manually scrolling back in the conversation to look for something.Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/712Throw FormatException if BdfList index is out of bounds2017-12-18T07:40:39ZakwizgranThrow FormatException if BdfList index is out of boundsCurrently an ArrayIndexOutOfBoundsException will be thrown, which could be a source of crashes when parsing untrusted data.Currently an ArrayIndexOutOfBoundsException will be thrown, which could be a source of crashes when parsing untrusted data.Milestone Eakwizgranakwizgranhttps://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/709Implement protocol for private group invitations2017-12-18T07:40:39ZakwizgranImplement protocol for private group invitationsSpec ticket is #659. Subtask of #127.Spec ticket is #659. Subtask of #127.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/708Implement protocol for private group messaging2017-12-18T07:40:39ZakwizgranImplement protocol for private group messagingSpec ticket is #658. Subtask of #127.Spec ticket is #658. Subtask of #127.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/707Implement UX for showing and answering private group invitations2017-12-18T07:40:39ZTorsten GroteImplement UX for showing and answering private group invitationsDepends on #648. Subtask of #127.
![](https://code.briarproject.org/akwizgran/briar/uploads/2cfb10c1cc3ebd85804b6fd0d7edae24/648_B_flow.jpg)Depends on #648. Subtask of #127.
![](https://code.briarproject.org/akwizgran/briar/uploads/2cfb10c1cc3ebd85804b6fd0d7edae24/648_B_flow.jpg)Milestone ETorsten 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/703Create fake test data while using the app2017-10-10T09:16:00ZakwizgranCreate fake test data while using the appWhen testing the app it would be useful to be able to generate fake contacts, groups and messages quickly.
* Add a contact (saving the identity private key somewhere so we can create signed messages later)
* Add 100 private messages to/...When testing the app it would be useful to be able to generate fake contacts, groups and messages quickly.
* Add a contact (saving the identity private key somewhere so we can create signed messages later)
* Add 100 private messages to/from a fake contact
* Add 100 posts to a forum (nested replies from a mixture of throwaway fake identities, fake contacts and the user's own identity)
* Add 100 posts to a blog (comment chains from a mixture of throwaway fake identities, fake contacts and the user's own identity - these could be posted to the blogs of fake contacts or the user's own blog)
Alternatively, instead of creating the messages in batches, we could start a background service that generates them at random intervals until shutdown. That would also allow us to test notifications, UI updates, etc.Android 1.0Torsten GroteTorsten Grotehttps://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 Grote