briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-09-27T08:10:08Zhttps://code.briarproject.org/briar/briar-desktop/-/issues/364Revise usage of disabled buttons2022-09-27T08:10:08ZMikolai GütschowRevise usage of disabled buttonsas a follow-up of https://code.briarproject.org/briar/briar-desktop/-/issues/343#note_67101
TD;LR: We should reconsider if we really need disabled buttons as they are bad practice UX-wise and especially for accessibility.as a follow-up of https://code.briarproject.org/briar/briar-desktop/-/issues/343#note_67101
TD;LR: We should reconsider if we really need disabled buttons as they are bad practice UX-wise and especially for accessibility.https://code.briarproject.org/briar/briar/-/issues/2328Crash when dragging and dropping in BlogActivity2022-06-09T16:11:35ZakwizgranCrash when dragging and dropping in BlogActivity* Android version: 10
* Phone model: DOOGEE S88Pro (S88Pro_EEA)
* Briar version: 1.4.5 (4df523a)
Last lines of log:
```
03-25 18:02:55.609 I/BaseActivity: Pausing NavDrawerActivity
03-25 18:02:55.623 I/BaseActivity: Creating BlogActivit...* Android version: 10
* Phone model: DOOGEE S88Pro (S88Pro_EEA)
* Briar version: 1.4.5 (4df523a)
Last lines of log:
```
03-25 18:02:55.609 I/BaseActivity: Pausing NavDrawerActivity
03-25 18:02:55.623 I/BaseActivity: Creating BlogActivity
03-25 18:02:55.640 I/BlogPostFragment: Adding Handler Callback
03-25 18:02:55.641 I/BaseActivity: Starting BlogActivity
03-25 18:02:55.641 I/BaseActivity: Resuming BlogActivity
03-25 18:02:56.113 I/BaseActivity: Stopping NavDrawerActivity
```
Stacktrace:
```
java.lang.IllegalStateException: Drag shadow dimensions must be positive
at android.view.View.startDragAndDrop(View.java:25599)
at android.widget.Editor.startDragAndDrop(Editor.java:1183)
at android.widget.Editor.performLongClick(Editor.java:1209)
at android.widget.TextView.performLongClick(TextView.java:12217)
at android.view.View.performLongClick(View.java:7211)
at android.view.View$CheckForLongPress.run(View.java:27500)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7386)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:980)
```
Looks like a platform bug so I'm not adding it to the current milestone.https://code.briarproject.org/briar/briar/-/issues/2327NPE when choosing notification sound2022-06-09T16:07:36ZakwizgranNPE when choosing notification sound* Android version: not provided
* Phone model: not provided
* Briar version: 1.4.5 (4df523a)
Stacktrace:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Class java.lang.Object.getClass()' on a null object...* Android version: not provided
* Phone model: not provided
* Briar version: 1.4.5 (4df523a)
Stacktrace:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Class java.lang.Object.getClass()' on a null object reference
at org.briarproject.briar.android.settings.NotificationsFragment.onNotificationSoundClicked(NotificationsFragment.java:218)
at org.briarproject.briar.android.settings.NotificationsFragment.lambda$onCreatePreferences$0(NotificationsFragment.java:108)
at org.briarproject.briar.android.settings.NotificationsFragment.$r8$lambda$tuVFVxovM6wElFyU0NWBFxLNE14(NotificationsFragment.java)
at org.briarproject.briar.android.settings.NotificationsFragment$$ExternalSyntheticLambda6.onPreferenceClick(Unknown Source)
at androidx.preference.Preference.performClick(Preference.java:1184)
at androidx.preference.Preference.performClick(Preference.java:1166)
at androidx.preference.Preference$1.onClick(Preference.java:181)
at android.view.View.performClick(View.java:5265)
at android.view.View$PerformClick.run(View.java:21534)
at android.os.Handler.handleCallback(Handler.java:815)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loop(Looper.java:207)
at android.app.ActivityThread.main(ActivityThread.java:5765)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:789)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:679)
```
Looks like the UI assumes the value of the `notifySound` LiveData will have been set, but it's not set until the settings have been loaded.
I thought we used to disable the UI until the settings were loaded, to avoid bugs like this. Maybe that was lost when we restructured the settings UI?Android 1.4https://code.briarproject.org/briar/briar-mailbox/-/issues/129Accessibility optimizations2023-08-28T16:00:12ZSebastianAccessibility optimizationsWe could check that accessibility is working nicely within the app, i.e. screenreaders can give visually impaired users a nice overview across the different workflows and fragments.We could check that accessibility is working nicely within the app, i.e. screenreaders can give visually impaired users a nice overview across the different workflows and fragments.https://code.briarproject.org/briar/briar/-/issues/2325Tor stops launching OR connections2022-06-06T14:43:27ZakwizgranTor stops launching OR connections* Android version: 12 (CalyxOS 3.5.1)
* Phone model: Pixel 3a
* Briar version: 1.4.8 (4623d03c937e176f81fcfbc40a909c6932ccafe0)
While smoke testing the 1.4.8 release I was quickly toggling the Tor settings (enabling/disabling Tor, enabl...* Android version: 12 (CalyxOS 3.5.1)
* Phone model: Pixel 3a
* Briar version: 1.4.8 (4623d03c937e176f81fcfbc40a909c6932ccafe0)
While smoke testing the 1.4.8 release I was quickly toggling the Tor settings (enabling/disabling Tor, enabling/disabling bridges, enabling/disabling Tor on battery) when Tor got stuck in the ENABLING state.
This bug seems to be distinct from #2324. Tor is still responding to control port commands, but it's failing to launch any OR connections to bridges. Unlike #2324, the Tor plugin shuts down normally.
Log: [pixel-3a-no-or-connections.txt](/uploads/eb9af1ae05c65a9e945708a8103904dc/pixel-3a-no-or-connections.txt)
The log shows that between 11:11:15 and 11:11:19 I disabled and re-enabled Tor several times with bridges enabled. At 11:11:15.283 I disabled Tor, and as expected the existing OR connections were closed. At 11:11:15.518 I re-enabled Tor but no OR connections were launched. I kept disabling and re-enabling Tor with bridges enabled, without any OR connections being launched. At 11:15:14.774 I disabled bridges. Tor then launched OR connections as expected and connected to the network.
At 11:15:20.020 I re-enabled bridges. At 11:15:27.927 I disabled Tor, and as expected the existing OR connections were closed. At 11:15:32.090 I re-enabled Tor and once again, no OR connections were launched. At 11:16:46.614 I disabled bridges, and once again this caused Tor to launch OR connections and connect to the network.
Later I was able to trigger the bug again on the same device by enabling bridges, then repeatedly disabling and re-enabling Tor. But I couldn't reproduce the bug on another device.
Log: [pixel-3a-no-or-connections-again.txt](/uploads/92cd2a0265f8816a0e43acec940c43bc/pixel-3a-no-or-connections-again.txt)
The second log contains the message "Ignoring directory request, since no bridge nodes are available yet", which isn't present in the first log.
Later I relaunched the app from AS to rule out the possibility of the `bridges` resource not having been included in the APK. After relaunching I didn't immediately manage to reproduce the bug by enabling bridges and repeatedly disabling and re-enabling Tor. But after disabling and re-enabling bridges a few times as well as disabling and re-enabling Tor, I saw the bug again.
Log: [pixel-3a-no-or-connections-yet-again.txt](/uploads/4f0e60b6cd7ffd7414a38ab125fc4cf6/pixel-3a-no-or-connections-yet-again.txt)
The third log contains a new message that wasn't present in the previous logs: "Application request when we haven't used client functionality lately. Optimistically trying known bridges again." This might suggest that Tor is deliberately not launching OR connections because it thinks the bridges are unavailable - perhaps due to previous connection failures caused by disabling and re-enabling Tor and/or bridges?https://code.briarproject.org/briar/briar/-/issues/2324Tor stops responding to control port2022-06-06T14:40:46ZakwizgranTor stops responding to control port* Android version: 9
* Phone model: Motorola Moto E6 Play
* Briar version: 1.4.8 (4623d03c937e176f81fcfbc40a909c6932ccafe0)
While smoke testing the 1.4.8 release I was quickly toggling the Tor settings (enabling/disabling Tor, enabling/...* Android version: 9
* Phone model: Motorola Moto E6 Play
* Briar version: 1.4.8 (4623d03c937e176f81fcfbc40a909c6932ccafe0)
While smoke testing the 1.4.8 release I was quickly toggling the Tor settings (enabling/disabling Tor, enabling/disabling bridges, enabling/disabling Tor on battery) when Briar stopped responding to changes in the Tor settings.
After this happened, each time I changed the settings the Tor plugin still logged "Tor settings updated", indicating that the new settings had been written to the DB and detected by the plugin. But the usual log messages that would follow from updateConnectionStatus() didn't appear.
When I signed out, the plugin logged "Stopping Tor" but then the stop() method didn't return. Eventually I had to force-stop the app.
I spent a long time trying to reproduce the bug, but wasn't able to.
At first I suspected the problem might be caused by the PoliteExecutor that runs the lambdas created by updateConnectionStatus(), but that executor isn't used when stopping Tor. The fact that the stop() method didn't return suggests that the problem is either in jtorctl or in Tor itself (I think a bug in jtorctl is more likely).
Log: [moto-e6-tor-settings-updated.txt](/uploads/aaf30977794c5b935de8e1d5a53d955f/moto-e6-tor-settings-updated.txt)
Before the bug happened, the TorPlugin was logging some long queue times for tasks running on the PoliteExecutor, so in some cases the settings were being changed again before the previous changes had been applied to Tor. But this on its own isn't enough to reproduce the bug: adding a sleep to the end of the lambda created by updateConnectionStatus() caused long queue times but didn't trigger the bug.https://code.briarproject.org/briar/briar-desktop/-/issues/362Profile picture in conversation header isn't updated2022-06-06T10:21:54ZakwizgranProfile picture in conversation header isn't updatedMinor cosmetic bug: the profile picture in the conversation header isn't updated when the contact sets a new profile picture (the one in the contact list is updated, however).
Switching to another conversation and back causes the header...Minor cosmetic bug: the profile picture in the conversation header isn't updated when the contact sets a new profile picture (the one in the contact list is updated, however).
Switching to another conversation and back causes the header to be updated.https://code.briarproject.org/briar/briar-mailbox/-/issues/127Use better mechanism than counting number of descriptor uploads to determine ...2023-08-28T16:00:12ZSebastianUse better mechanism than counting number of descriptor uploads to determine published state of TorIt was reported that counting uploads of the descriptor isn't maybe the best metric.
So first we test connecting without waiting for descriptor uploads right after bootstrapping. Then we test waiting for one upload.
Test instructions:
...It was reported that counting uploads of the descriptor isn't maybe the best metric.
So first we test connecting without waiting for descriptor uploads right after bootstrapping. Then we test waiting for one upload.
Test instructions:
* uninstall mailbox app on test device (or clear app data in settings)
* install mailbox version from [`127-no-tor-wait-after-bootstrapping`](https://code.briarproject.org/briar/briar-mailbox/commits/127-no-tor-wait-after-bootstrapping)
* prepare briar app on another device for scanning
* go through onboarding on mailbox app
* try to record the time the progress bar is shown
* as soon as mailbox app shows QR code scan it with briar as fast as possible
* record whether the first attempt was successful or failed
Test variation:
* as above, but use current `main` branch of mailbox apphttps://code.briarproject.org/briar/briar/-/issues/2322When Tor not active, adding a RSS feed fails with unclear error message2022-10-11T12:02:07ZAminda SuomalainenWhen Tor not active, adding a RSS feed fails with unclear error messageIf the option to connect to internet only when charging is set, feeds cannot be added or there will be an error message (which content I don't have at hand, but doesn't clearly tell what the issue is) and suggests trying again, which wil...If the option to connect to internet only when charging is set, feeds cannot be added or there will be an error message (which content I don't have at hand, but doesn't clearly tell what the issue is) and suggests trying again, which will result to the same problem.
The solution is to either uncheck the option or put the phone to charge and it will be able to add feeds without issues.
I think https://code.briarproject.org/briar/briar/-/issues/2247 would be a potential solution to this, but having the error message say that connecting to internet or unchecking the box is required.
Briar 1.4.7 (more device details in #2321)https://code.briarproject.org/briar/briar/-/issues/2321Deduplicate RSS feeds2022-06-03T18:21:42ZAminda SuomalainenDeduplicate RSS feedsWhen two users add an RSS feed and share it to each other, Briar doesn't detect it to be the same and shows everything twice in Blogs. I think Briar should notice that they are the same and at least hide the duplicate from user.
I am al...When two users add an RSS feed and share it to each other, Briar doesn't detect it to be the same and shows everything twice in Blogs. I think Briar should notice that they are the same and at least hide the duplicate from user.
I am also unclear on whether both devices are able to check the feed for updates or if it only updates when the device originally adding the feed checks it.
Reproducing:
1. Add a feed
2. Share the feed to another device/user
3. Accept the share on another device
4. Also manually add the same feed
5. Possibly share it to the first device
6. After accepting, both users see the same.
I am using `Briar 1.4.7` from F-Droid (I guess as Android reports the source to be "Package installer") on Android 10 Go Edition (Nokia 1 TA-1047). The other device is 1.4.7 from Aurora Store on SailfishOS Android Support that pretends to be Android 10 on Xperia 10 II (but due to not being real Android has random unrelated issues).https://code.briarproject.org/briar/briar-mailbox/-/issues/124Handle Huawei and Xiaomi auto-start restrictions2023-08-28T16:01:38ZTorsten GroteHandle Huawei and Xiaomi auto-start restrictionsHuawei has a `StartupManager` where the user needs to allow the app to start: https://stackoverflow.com/a/43914328/4856311
For Xiaomi MIUI there's even a library to check autostart permissions: https://github.com/XomaDev/MIUI-autostart ...Huawei has a `StartupManager` where the user needs to allow the app to start: https://stackoverflow.com/a/43914328/4856311
For Xiaomi MIUI there's even a library to check autostart permissions: https://github.com/XomaDev/MIUI-autostart It seems to use pre-built jars though
If the library isn't helpful, maybe we can bring the user as close to the right screen as possible.
The other vendors preventing auto-start have way smaller market share, maybe not worth dealing with those as well?https://code.briarproject.org/briar/briar-desktop/-/issues/360App fails to shut down when jar has been overwritten2023-08-25T13:33:35ZakwizgranApp fails to shut down when jar has been overwrittenSteps to reproduce:
* Build briar-desktop jars using different commits for the `briar` submodule (I used `release-1.4.7` (https://code.briarproject.org/briar/briar/-/commit/7536f16c6136ebd5700a0f0ad49441050cf60096) and `poll-own-hidden-s...Steps to reproduce:
* Build briar-desktop jars using different commits for the `briar` submodule (I used `release-1.4.7` (https://code.briarproject.org/briar/briar/-/commit/7536f16c6136ebd5700a0f0ad49441050cf60096) and `poll-own-hidden-service` (https://code.briarproject.org/briar/briar/-/commit/aeac73175910585abc490d06f55a725c6eef6fb8))
* Start briar-desktop using the first jar
* Sign in
* Overwrite the first jar with the second jar
* Close the briar-desktop window
Expected behaviour:
* The window closes and the process exits
* It's possible to relaunch briar-desktop and sign in
Actual behaviour:
* The window doesn't close on the first attempt
* On the second attempt, the window closes but the process remains running
* It's possible to relaunch briar-desktop, but attempting to sign in shows the "Sorry, Briar was unable to open the database" error screen (due to the database still being locked by the original process)
* After killing the original process manually it's possible to relaunch briar-desktop and sign in
On the first attempt to close the window results in various NoClassDefFoundErrors when the JVM fails to load classes that are used during shutdown. I guess the exact exceptions may depend on which branches are used to reproduce the bug, but I got an exception for `PluginManagerImpl$PluginStopper`, for example. These exceptions seem to prevent `LifecycleManager#stopServices()` from shutting down the core.
```
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: org/briarproject/bramble/plugin/PluginManagerImpl$PluginStopper
at org.briarproject.bramble.plugin.PluginManagerImpl.stopService(PluginManagerImpl.java:157)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl.stopServices(LifecycleManagerImpl.java:198)
at org.briarproject.briar.desktop.ui.BriarUiImpl.stop(BriarUi.kt:109)
at org.briarproject.briar.desktop.Main$run$8$1.invoke(Main.kt:124)
at org.briarproject.briar.desktop.Main$run$8$1.invoke(Main.kt:123)
at androidx.compose.ui.window.Window_desktopKt$Window$3$1$1.windowClosing(Window.desktop.kt:166)
at java.desktop/java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:357)
at java.desktop/java.awt.Window.processWindowEvent(Window.java:2078)
at java.desktop/javax.swing.JFrame.processWindowEvent(JFrame.java:298)
at java.desktop/java.awt.Window.processEvent(Window.java:2037)
at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011)
at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.ClassNotFoundException: org.briarproject.bramble.plugin.PluginManagerImpl$PluginStopper
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 31 more
```
Incidentally, the stacktrace seems to show that `BriarUiImpl#stop()` is calling `LifecycleManager#stopServices()` on the UI thread, which it probably shouldn't.
The second attempt to close the window results in another NoClassDefFoundError that apparently kills the UI and thus closes the window, but still without killing the core.
```
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: kotlinx/coroutines/CoroutinesInternalError
at kotlinx.coroutines.DispatchedTask.handleFatalException(DispatchedTask.kt:144)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:115)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.ClassNotFoundException: kotlinx.coroutines.CoroutinesInternalError
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 15 more
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: kotlinx/coroutines/CoroutinesInternalError
at kotlinx.coroutines.DispatchedTask.handleFatalException(DispatchedTask.kt:144)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:115)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: kotlinx/coroutines/CoroutinesInternalError
at kotlinx.coroutines.DispatchedTask.handleFatalException(DispatchedTask.kt:144)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:115)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
```Desktop 0.7.0https://code.briarproject.org/briar/briar-desktop/-/issues/359Auto-generate screenshots with reasonable text2022-10-25T10:30:06ZMikolai GütschowAuto-generate screenshots with reasonable textSomething comparable to the screenshot currently shown on https://briarproject.org/download-briar-desktop/ or the [Android screenshots on Google Play](https://play.google.com/store/apps/details?id=org.briarproject.briar.android).
For th...Something comparable to the screenshot currently shown on https://briarproject.org/download-briar-desktop/ or the [Android screenshots on Google Play](https://play.google.com/store/apps/details?id=org.briarproject.briar.android).
For this we need (in a separate build configuration):
- some nice conversations, also including special "messages" like introduction requests (can be added to our deterministic test data)
- ability to fake some contact connection statuses in code (show contacts as connected for screenshot)
- usage of compose built-in snapshot feature (see https://dev.to/pchmielowski/automate-taking-screenshots-of-android-app-with-jetpack-compose-2950 as reference)https://code.briarproject.org/briar/briar-desktop/-/issues/358Revise Dispatchers.Swing usage to run code on UI thread2022-09-04T20:23:27ZSebastianRevise Dispatchers.Swing usage to run code on UI threadThe following discussion from !199 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/199#note_66074): (+1 comment)
> I had to add this explicit dependency...The following discussion from !199 should be addressed:
- [ ] @ialokim started a [discussion](https://code.briarproject.org/briar/briar-desktop/-/merge_requests/199#note_66074): (+1 comment)
> I had to add this explicit dependency as described at https://github.com/JetBrains/compose-jb/releases/tag/v1.1.1.
>
> They also state that our use of Dispatchers.Swing that relies on Compose internally using this dispatcher for the UI drawing is probably not future-proof. We might want to look again into binding the events to a coroutineScope instead (related to #336).https://code.briarproject.org/briar/briar-desktop/-/issues/357Error displayed on console after exiting application2022-05-11T14:59:47ZSebastianError displayed on console after exiting applicationWhen I launch the app as installed via the `*.deb` file, after exiting the application I see this output:
```
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
```
Even when no AWT window is ...When I launch the app as installed via the `*.deb` file, after exiting the application I see this output:
```
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
```
Even when no AWT window is being displayed, i.e. also for `briar-desktop --help`.
It doesn't happen when I run the app using the jar with OpenJDK 17 and `java -jar briar-desktop.jar`.
So it might have to do with the native executable and the JRE shipped withe the debian package built by jpackage.https://code.briarproject.org/briar/briar-desktop/-/issues/351Specifiying different tor control and socks ports after first launch doesn't ...2022-06-29T13:00:53ZSebastianSpecifiying different tor control and socks ports after first launch doesn't workOn first start of the TorPlugin, the config file is created on the fly and stored in `$ACCOUNT_DIR/tor/torrc`. It is not rewritten on subsequent starts of the TorPlugin, hence when different Tor ports are specified the tor process is sta...On first start of the TorPlugin, the config file is created on the fly and stored in `$ACCOUNT_DIR/tor/torrc`. It is not rewritten on subsequent starts of the TorPlugin, hence when different Tor ports are specified the tor process is started with the old ports specified in the torrc file while the plugin tries to communicate with the tor process on the new ports, which fails.https://code.briarproject.org/briar/briar-desktop/-/issues/349FAB in chat window not shown if older message arrives out-of-order2023-08-25T13:33:35ZMikolai GütschowFAB in chat window not shown if older message arrives out-of-orderThis issue was encountered while testing for release 0.2.1 #346. We would need to have a way to reproduce this (e.g. by sending some message from a test contact after a given time in TestData).
Nevertheless, the message counter in the c...This issue was encountered while testing for release 0.2.1 #346. We would need to have a way to reproduce this (e.g. by sending some message from a test contact after a given time in TestData).
Nevertheless, the message counter in the contact list was updated (directly after?) receiving the out-of-order message and after changing to another chat and navigating back to the chat with the new message, the scrollview was automatically scrolled to the new message.Desktop 0.7.0https://code.briarproject.org/briar/briar-desktop/-/issues/348AddContactDialog: display error on link input if link not in correct format2022-05-11T06:57:46ZSebastianAddContactDialog: display error on link input if link not in correct formatWhile testing !202 I noticed we don't set the `isError` property of the input field for the contact's link. I think that would be useful to make the user aware of invalid format before confirming the dialog.While testing !202 I noticed we don't set the `isError` property of the input field for the contact's link. I think that would be useful to make the user aware of invalid format before confirming the dialog.https://code.briarproject.org/briar/briar-mailbox/-/issues/119Allow navigating back to onboarding activity2023-08-28T16:00:09ZIvanaAllow navigating back to onboarding activityA question arose during the testing of the implementation of #32
The context: When a user installs the app, the first screen they see gives them two options: either skip intro, or walk through intro.
If the user skips intro, then the...A question arose during the testing of the implementation of #32
The context: When a user installs the app, the first screen they see gives them two options: either skip intro, or walk through intro.
If the user skips intro, then they see the do-not-kill-me fragment, which asks them to "Allow connections"... ithout tapping on that button they cannot continue, as the "Continue button" is disabled.
If the user does skip the intro, this is the next screen they see. If the user tries to navigate back, they are kicked out of the app. This may be OK, as the only previous screen is the 'home' screen? Or should the user be able to navigate back to it?
If the user does not skip the intro, they can navigate back and forth between the 4 intro screens, which is OK. However, after the 4th intro screen, the 'do not kill me' fragment is shown to them, and from there they cannot navigate back. A user may want to navigate back if they accidentally pressed the Continue button on the previous screen before thye properly read the contents? But if the user tries to navigate back to the previous screen, they are kicked out of the app.
To be considered: is the navigation back from the 'do not kill me' to the previous screen something that we would want to see implemented? Or not?
In any case, this is a Low priority now, because it is not necessary for the first version of the product. If the decision is made to address this and implement it, then it is a nice to have for the first version - ie only to be implemented if we have lots of time to spare. At the moment **NOT SPONSOR6**
If the decision is made to not implement it even in future releases, then this ticket can be closed.https://code.briarproject.org/briar/briar/-/issues/2317Restarting app quickly after startup failure sometimes does not work2022-05-04T10:43:53ZSebastianRestarting app quickly after startup failure sometimes does not work