briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-01-09T21:29:50Zhttps://code.briarproject.org/briar/briar-desktop/-/issues/131Allow to easily re-add failed pending contacts2023-01-09T21:29:50ZNicoAllow to easily re-add failed pending contactsInstead of having to re-paste briar:// links, would be cool if we could automate this by clicking a button on failed pending contacts.Instead of having to re-paste briar:// links, would be cool if we could automate this by clicking a button on failed pending contacts.Desktop 1.0.0https://code.briarproject.org/briar/briar/-/issues/2407Crash when getting Bluetooth address2023-01-06T16:28:57ZakwizgranCrash when getting Bluetooth address* Android version: 12
* Phone model: Redmi M2004J19C (galahad_global)
* Briar version: 1.4.18 (4797151)
Edited log:
```
12-17 21:55:20.433 I/AbstractBluetoothPlugin: Bluetooth enabled
```
Stacktrace:
```
java.lang.SecurityException: Ne...* Android version: 12
* Phone model: Redmi M2004J19C (galahad_global)
* Briar version: 1.4.18 (4797151)
Edited log:
```
12-17 21:55:20.433 I/AbstractBluetoothPlugin: Bluetooth enabled
```
Stacktrace:
```
java.lang.SecurityException: Need android.permission.BLUETOOTH_CONNECT permission for android.content.AttributionSource@458c6c33: getAddress
at android.os.Parcel.createExceptionOrNull(Parcel.java:2426)
at android.os.Parcel.createException(Parcel.java:2410)
at android.os.Parcel.readException(Parcel.java:2393)
at android.os.Parcel.readException(Parcel.java:2335)
at android.bluetooth.IBluetoothManager$Stub$Proxy.getAddress(IBluetoothManager.java:789)
at android.bluetooth.BluetoothAdapter.getAddress(BluetoothAdapter.java:1290)
at org.briarproject.bramble.util.AndroidUtils.getBluetoothAddressAndMethod(AndroidUtils.java:70)
at org.briarproject.bramble.util.AndroidUtils.getBluetoothAddress(AndroidUtils.java:63)
at org.briarproject.bramble.plugin.bluetooth.AndroidBluetoothPlugin.getBluetoothAddress(AndroidBluetoothPlugin.java:146)
at org.briarproject.bramble.plugin.bluetooth.AbstractBluetoothPlugin.updateProperties(AbstractBluetoothPlugin.java:239)
at org.briarproject.bramble.plugin.bluetooth.AbstractBluetoothPlugin.$r8$lambda$ZdCFKGKAr5elvl5L48zy5sncMIA(Unknown Source:0)
at org.briarproject.bramble.plugin.bluetooth.AbstractBluetoothPlugin$$ExternalSyntheticLambda2.run(Unknown Source:2)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:920)
Caused by: android.os.RemoteException: Remote stack trace:
at com.android.server.BluetoothManagerService.checkPermissionForDataDelivery(BluetoothManagerService.java:3327)
at com.android.server.BluetoothManagerService.checkConnectPermissionForDataDelivery(BluetoothManagerService.java:3345)
at com.android.server.BluetoothManagerService.getAddress(BluetoothManagerService.java:1951)
at android.bluetooth.IBluetoothManager$Stub.onTransact(IBluetoothManager.java:373)
at android.os.Binder.execTransactInternal(Binder.java:1190)
```Android 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1698SecurityException when binding Bluetooth socket2022-12-28T13:18:55ZakwizgranSecurityException when binding Bluetooth socket* Android version: 9
* Phone model: Honor COL-L29 (COL-L29RU)
* Briar version: 1.2.4 (75dfa80)
Stacktrace:
```
java.lang.SecurityException: Not allowed for non-active users
at android.os.Parcel.createException(Parcel.java:1953)
...* Android version: 9
* Phone model: Honor COL-L29 (COL-L29RU)
* Briar version: 1.2.4 (75dfa80)
Stacktrace:
```
java.lang.SecurityException: Not allowed for non-active users
at android.os.Parcel.createException(Parcel.java:1953)
at android.os.Parcel.readException(Parcel.java:1921)
at android.os.Parcel.readException(Parcel.java:1871)
at android.bluetooth.IBluetoothSocketManager$Stub$Proxy.createSocketChannel(IBluetoothSocketManager.java:207)
at android.bluetooth.BluetoothSocket.bindListen(BluetoothSocket.java:456)
at android.bluetooth.BluetoothAdapter.createNewRfcommSocketAndRecord(BluetoothAdapter.java:2152)
at android.bluetooth.BluetoothAdapter.listenUsingInsecureRfcommWithServiceRecord(BluetoothAdapter.java:2103)
at org.briarproject.bramble.plugin.bluetooth.AndroidBluetoothPlugin.openServerSocket(AndroidBluetoothPlugin.java:158)
at org.briarproject.bramble.plugin.bluetooth.AndroidBluetoothPlugin.openServerSocket(AndroidBluetoothPlugin.java:57)
at org.briarproject.bramble.plugin.bluetooth.BluetoothPlugin.lambda$bind$0$BluetoothPlugin(BluetoothPlugin.java:179)
at org.briarproject.bramble.plugin.bluetooth.-$$Lambda$BluetoothPlugin$5LFrMRmXQDZNSHk-RYMiHxB1iBE.run(Unknown Source:2)
at java.util.concurrent.ThreadPoolExecutor.processTask(ThreadPoolExecutor.java:1187)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:784)
```
Edited log:
```
12-23 13:01:56.423 I/AndroidNetworkManager: Received broadcast android.intent.action.SCREEN_OFF
...
12-23 13:01:57.318 I/AndroidNetworkManager: Received broadcast android.intent.action.SCREEN_ON
...
12-23 13:02:01.460 I/AndroidBluetoothPlugin: Scan mode: None
12-23 13:02:02.034 I/AndroidBluetoothPlugin: Scan mode: None
12-23 13:02:02.051 I/BluetoothPlugin: java.io.IOException: read failed, socket might closed or timeout, read ret: -1
12-23 13:02:02.069 I/BluetoothPlugin: Bluetooth disabled
12-23 13:02:02.070 I/BluetoothConnectionLimiterImpl: All connections closed
...
12-23 13:02:05.087 I/BluetoothPlugin: Bluetooth enabled
12-23 13:02:05.257 I/BluetoothPlugin: Local address null
```
No activities are shown stopping/starting when the screen turns off/on, which suggests Briar's running in the background. Looks like there might be a restriction on background apps binding Bluetooth sockets.Android 1.4https://code.briarproject.org/briar/briar-mailbox/-/issues/177Having stop button beside connection indicator is confusing2022-12-16T15:22:50ZakwizgranHaving stop button beside connection indicator is confusing> Having the “Stop” button near the check mark is confusing as it makes it look like a button instead of an indicator. I’d suggest you move the “Stop” button below the “Last connection...” text.> Having the “Stop” button near the check mark is confusing as it makes it look like a button instead of an indicator. I’d suggest you move the “Stop” button below the “Last connection...” text.Mailbox: Usability testingSebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2403Not enough feedback while connecting to Mailbox2022-12-15T13:02:08ZakwizgranNot enough feedback while connecting to Mailbox> Sometimes the connection took a long time while setting up the Mailbox. In these cases, a few participants assumed that they were having problems with either the app or the internet connection. There is not enough feedback for the user...> Sometimes the connection took a long time while setting up the Mailbox. In these cases, a few participants assumed that they were having problems with either the app or the internet connection. There is not enough feedback for the user on this screen.Mailbox: Usability testingIvanaIvanahttps://code.briarproject.org/briar/briar-desktop/-/issues/390Image compressor unable to compress file to 32kb2022-12-09T08:26:46ZSebastianImage compressor unable to compress file to 32kbI found an image for which our ImageCompressor implementation fails to compress it to the required file size:
https://unsplash.com/photos/EHcIO_3DbOg
This is the log:
```
Exception in thread "Thread-13" java.io.IOException
at o...I found an image for which our ImageCompressor implementation fails to compress it to the required file size:
https://unsplash.com/photos/EHcIO_3DbOg
This is the log:
```
Exception in thread "Thread-13" java.io.IOException
at org.briarproject.briar.desktop.attachment.media.ImageCompressorImpl.compressImage(ImageCompressorImpl.kt:86)
at org.briarproject.briar.desktop.conversation.ConversationViewModel$sendMessage$1.invoke(ConversationViewModel.kt:180)
at org.briarproject.briar.desktop.conversation.ConversationViewModel$sendMessage$1.invoke(ConversationViewModel.kt:175)
at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
```
[ImageCompressorImpl.kt:86](https://code.briarproject.org/briar/briar-desktop/-/blob/main/briar-desktop/src/main/kotlin/org/briarproject/briar/desktop/attachment/media/ImageCompressorImpl.kt#L86)
We have this there:
```kotlin
for (quality in 100 downTo 1 step 10) {
val jpgWriter = ImageIO.getImageWritersByFormatName("jpg").next()
jpgWriter.output = ImageIO.createImageOutputStream(out)
val jpgWriteParam = jpgWriter.defaultWriteParam
jpgWriteParam.compressionMode = ImageWriteParam.MODE_EXPLICIT
jpgWriteParam.compressionQuality = quality / 100f
val outputImage = IIOImage(scaled, null, null)
jpgWriter.write(null, outputImage, jpgWriteParam)
jpgWriter.dispose()
if (out.size() <= MAX_IMAGE_SIZE) {
LOG.i { "Compressed image to ${out.size()} bytes, quality $quality" }
return ByteArrayInputStream(out.toByteArray())
}
out.reset()
}
throw IOException()
```
I have not yet debugged this, but I'm wondering what the lowest quality is that we actually try. We start with 100 but do we reach 1 or 10 as the last value? Edit: I just checked. We never reach 1 but the lowest value we try is 10. I guess we probably should change this to try quality 1 and in doubt even reduce image dimensions if even that does not suffice.
This is the full image:
![imran-hecimovic-EHcIO_3DbOg-unsplash](/uploads/800f92fcdac18eb25a9e43417961d99a/imran-hecimovic-EHcIO_3DbOg-unsplash.jpg)https://code.briarproject.org/briar/briar/-/issues/2400Testers didn't realise that text buttons were buttons2022-12-07T16:54:37ZakwizgranTesters didn't realise that text buttons were buttons![buttons-1](/uploads/72a3c9f24adea51777db39592588ef50/buttons-1.png)
> A few participants didn’t notice the “Check connection settings” button. In this case, the “Try again” button grabs the attention and it’s hard to tell that “Check ...![buttons-1](/uploads/72a3c9f24adea51777db39592588ef50/buttons-1.png)
> A few participants didn’t notice the “Check connection settings” button. In this case, the “Try again” button grabs the attention and it’s hard to tell that “Check connection settings” is a button, it looks like a text/link.
![buttons-2](/uploads/965fe0ae27bc7520d2f1b1dc9e32ca31/buttons-2.png)
> The same goes for the screenshot on the right, “Fix problem” and “Unlink” look like links. There is a mismatch in these patterns. Use buttons in every case the user is required to take action and use colors to distinguish their importance.
We're using the Material 2 "text button" style for these buttons. Maybe we should use the "outlined button" style instead.
https://m2.material.io/components/buttons/android#using-buttons
There's also some inconsistency in the colouring: we're using the link colour for the "fix problem" button (like the positive button in dialogs), but the app's primary colour for the "check connection settings" button.Mailbox: Usability testingakwizgranakwizgranhttps://code.briarproject.org/briar/briar-desktop/-/issues/439Forum unread messages counter in forum list does not update when entries are ...2022-12-07T15:52:28ZSebastianForum unread messages counter in forum list does not update when entries are marked as readhttps://code.briarproject.org/briar/briar-desktop/-/issues/424Visual bug with long names in contact list2022-12-07T11:55:50ZMikolai GütschowVisual bug with long names in contact listJust experienced this after starting `TestRandomConversation`:
![image](/uploads/078a7c5b38970284de796b429fffc852/image.png)Just experienced this after starting `TestRandomConversation`:
![image](/uploads/078a7c5b38970284de796b429fffc852/image.png)Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-mailbox/-/issues/176Not enough feedback while Mailbox is starting2022-11-30T11:04:52ZakwizgranNot enough feedback while Mailbox is starting> Sometimes the connection took a long time while setting up the Mailbox. In these cases, a few participants assumed that they were having problems with either the app or the internet connection. There is not enough feedback for the user...> Sometimes the connection took a long time while setting up the Mailbox. In these cases, a few participants assumed that they were having problems with either the app or the internet connection. There is not enough feedback for the user on this screen.Mailbox: Usability testinghttps://code.briarproject.org/briar/briar-mailbox/-/issues/158CLI does not respond to Ctrl+C any longer2022-11-30T08:03:07ZSebastianCLI does not respond to Ctrl+C any longerCtrl+C is supposed to shutdown the CLI app and we also want to shutdown the lifecycle cleanly before exiting. To achieve this, we register a shutdown hook before starting the lifecycle which gets called in response to the signal.
Note: ...Ctrl+C is supposed to shutdown the CLI app and we also want to shutdown the lifecycle cleanly before exiting. To achieve this, we register a shutdown hook before starting the lifecycle which gets called in response to the signal.
Note: it looks like the shutdown hooks do not (and did never) run when the mailbox cli is run using gradle, i.e. `./gradlew run --args=-v` won't trigger the shutdown hooks when a shutdown signal is received. So we need to build the jar using `./gradlew x86LinuxJar` and run it using `java -jar mailbox-cli/build/libs/mailbox-cli-linux-x86_64.jar` to observe if things are working or not.
Currently, pressing Ctrl+C leads to a deadlock. This is what is happening:
* Ctrl+C initiates a shutdown of the VM
* The shutdown hooks get started, including the one we registered before starting the lifecycle
* our shutdown hook calls `LifecycleManager#stopServices()`
* `stopServices()` calls `exitProcess(0)` in its finally block
* This leads to deadlock.
The cause for the deadlock is described in the documentation of [Runtime#exit](https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#exit(int)):
> Terminates the currently running Java virtual machine by initiating its shutdown sequence. [...]
>
> The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts.
>
> If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely. If shutdown hooks have already been run and on-exit finalization has been enabled then this method halts the virtual machine with the given status code if the status is nonzero; otherwise, it blocks indefinitely.
The important part being:
> If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely
And that is precisely what we are doing. Actually we're calling `Runtime.exit()` from within a shutdown hook which matches the conditions described above and causes indefinite blocking.
This got introduced with !99 and [we discussed this here](https://code.briarproject.org/briar/briar-mailbox/-/merge_requests/99#note_68524). I have the feeling it might not be the best idea after all to let the lifecycle manager exit the VM. Maybe it's better to let the individual starting points that use the lifecycle be responsible for that, i.e. the CLI, the Android app and the unit tests should handle that in some way that makes sense and works nicely in the respective scenario. I think a call to `Runtime.exit()` within the lifecycle manager is just a too drastic measure which is difficult to make work in all scenarios and we're making our life a lot harder by trying to make the starting points work around the fact that the lifecycle manager is calling exit() itself.
If we use the mailbox in integration tests, this will be a problem too, because the test frameworks cannot gracefully handle components that exit the VM either. I recently added an option to disable this exiting behavior on the branch for integration tests with briar: https://code.briarproject.org/briar/briar-mailbox/-/commit/a488bb20ef18784214ed903a3535db280a950830 and if I pass `false` as `exitAfterStopping` in the CLI the exiting using CTRL+C also works as expected again. So maybe that is a middle ground where we can have the exiting in the lifecycle where we wanted it to be as a result of the discussion where it should be for the Android app, and yet still be able to disable this for both the CLI and integration tests.SebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2154Reblogged entry appears duplicated in the main blog feed2022-11-23T16:02:58ZIvanaReblogged entry appears duplicated in the main blog feed**Steps to reproduce:**
Write a blog post and publish it.
Reblog it.
**Expected results:**
The reblogged entry is listed on top of the main blog feed, just once
**Actual results:**
The reblogged entry appears on top of the list in t...**Steps to reproduce:**
Write a blog post and publish it.
Reblog it.
**Expected results:**
The reblogged entry is listed on top of the main blog feed, just once
**Actual results:**
The reblogged entry appears on top of the list in the main blog feed, but it is duplicated. See the screenshot. ![device-2021-08-19-115546](/uploads/3e5487cecf1a8d889ca9c68116616360/device-2021-08-19-115546.png)
If then a new blog post is written, or even if the user taps onto a blogpost to go in and read it, and then returns to the main blog feed screen, the problem rights itself, and the duplicate doesn' show any more, see the screenshot
![device-2021-08-19-115754](/uploads/16f306efec8f250513b869093bdcab32/device-2021-08-19-115754.png)
It would seem that as soon as the main blog feed screen gets refreshed, the problem rights itself.https://code.briarproject.org/briar/briar/-/issues/689Line breaks entered in blog posts aren't displayed2022-11-23T14:44:51ZakwizgranLine breaks entered in blog posts aren't displayedWhen writing a blog post, I can use the enter key to create line breaks that are shown in the composition window. But they aren't shown when the blog post appears in the feed (presumably because it's rendered as HTML).When writing a blog post, I can use the enter key to create line breaks that are shown in the composition window. But they aren't shown when the blog post appears in the feed (presumably because it's rendered as HTML).https://code.briarproject.org/briar/briar/-/issues/865Blog: Testers did not understand the structure of the feed2022-11-18T17:24:07ZMegaloxBlog: Testers did not understand the structure of the feedThe testers were confused that an entry was shown again within the reblog and then a third time in the reblog of the reblog. The feed was full of the same blogpost, only that another part was added on top for every reblog.The testers were confused that an entry was shown again within the reblog and then a third time in the reblog of the reblog. The feed was full of the same blogpost, only that another part was added on top for every reblog.https://code.briarproject.org/briar/briar/-/issues/348Testers did not understand QR code workflow2022-11-18T17:24:07ZakwizgranTesters did not understand QR code workflowThree testers tried to scan each other's QR codes: A scanned B, B scanned C, and C scanned A. The testers were not able to complete the task.
In an earlier round of testing we encountered a similar problem with invitation codes.
The f...Three testers tried to scan each other's QR codes: A scanned B, B scanned C, and C scanned A. The testers were not able to complete the task.
In an earlier round of testing we encountered a similar problem with invitation codes.
The first step we should take is to detect that the device we've connected to isn't the same device we scanned, and show a helpful error message. But we may need to consider a more fundamental change: is it possible to design the key agreement protocol to accommodate what the users are trying to achieve?https://code.briarproject.org/briar/briar/-/issues/2047Main Blog feed page - snack bar 'Scroll to' not working after import of a new...2022-11-17T14:31:44ZIvanaMain Blog feed page - snack bar 'Scroll to' not working after import of a new RSS feedSteps to reproduce:
1. Go to Settings > Blogs > Import RSS Feed
2. Type in the address of an rss feed (I used these ones: https://www.ed.gov/feed, http://feeds.nature.com/nature/rss/current, http://www.newyorker.com/feed/humor)
3. After...Steps to reproduce:
1. Go to Settings > Blogs > Import RSS Feed
2. Type in the address of an rss feed (I used these ones: https://www.ed.gov/feed, http://feeds.nature.com/nature/rss/current, http://www.newyorker.com/feed/humor)
3. After a successful import, tap the back button (upper left hand side corner of the Briar app screen) to return to the main blog feed page
4. At the bottom of the screen there is a brief message 'new blog post received' and the tappable words 'SCROLL TO' in blue
5. Tap the SCROLL TO
Expected results:
1. Briar should scroll to the new blogs that have been received via the imported RSS feed
Actual results
1. No scrolling happens. Reproduced on Nokia 3.1, HTCOneM9 and Pixel2. ![device-2021-05-19-121740](/uploads/b3d3e0685ece690fea28db744a9e4bd0/device-2021-05-19-121740.mp4)
However, if after the RSS feed import I tap the device's own back button (on device, not on the app screen) to return to the main blog page, then scrolling happens correctly (and it does when other blogs are received as well). ![device-2021-05-19-121543](/uploads/e43c58468525c059cf35081cfc2a3171/device-2021-05-19-121543.mp4)
Master, dated 17.5 githash: b0faab9https://code.briarproject.org/briar/briar-desktop/-/issues/292Unclean program exit with core dump2022-11-13T19:23:43ZNicoUnclean program exit with core dumpA user reported that "whenever [they] exit the program it core dumps with the following error:
```
pure virtual method called
terminate called without an active exception
```
They are on 0.1.0-beta and using a i3 desktop environment.A user reported that "whenever [they] exit the program it core dumps with the following error:
```
pure virtual method called
terminate called without an active exception
```
They are on 0.1.0-beta and using a i3 desktop environment.https://code.briarproject.org/briar/briar-mailbox/-/issues/146Top of the battery icon cut off in landscape orientaiton - do-not-kill-me fra...2022-11-09T12:49:22ZIvanaTop of the battery icon cut off in landscape orientaiton - do-not-kill-me fragmentHere's the video that illustrates the battery icon being displayed incorrectly in landscape orientation - as you can see its top is cut off. Device Nokia 3.2
![device-2022-07-19-120230](/uploads/aaa939f5bc37ca422c96826c6c43faf4/devic...Here's the video that illustrates the battery icon being displayed incorrectly in landscape orientation - as you can see its top is cut off. Device Nokia 3.2
![device-2022-07-19-120230](/uploads/aaa939f5bc37ca422c96826c6c43faf4/device-2022-07-19-120230.mp4)
And here it is for Pixel 2
![device-2022-07-19-123616](/uploads/37ba0314cb407d55f6b9c0c8d16dbcae/device-2022-07-19-123616.mp4)SebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2383WIP Graphics not displayed in landscape orientation2022-11-08T12:48:58ZIvanaWIP Graphics not displayed in landscape orientationWorkflow: create new nearby contact
Documenting everything workflow by workflow.. will attach the docs when done.. this is a WIP ticketWorkflow: create new nearby contact
Documenting everything workflow by workflow.. will attach the docs when done.. this is a WIP tickethttps://code.briarproject.org/briar/briar/-/issues/2370Main class not specified in briar-headless.jar manifest2022-11-04T13:02:28ZakwizgranMain class not specified in briar-headless.jar manifestA user reported that when following the instructions for building and running briar-headless.jar, the JVM exits with `no main manifest attribute, in briar-headless/build/libs/briar-headless.jar`. I can reproduce this with OpenJDK 11.0.16...A user reported that when following the instructions for building and running briar-headless.jar, the JVM exits with `no main manifest attribute, in briar-headless/build/libs/briar-headless.jar`. I can reproduce this with OpenJDK 11.0.16. The manifest exists and contains a `Manifest-Version` attribute, but no `Main-Class` attribute.SebastianSebastian