briar issueshttps://code.briarproject.org/groups/briar/-/issues2024-03-19T16:03:18Zhttps://code.briarproject.org/briar/briar/-/issues/2331KeyStoreException: Invalid key blob2024-03-19T16:03:18ZakwizgranKeyStoreException: Invalid key blob* Android version: 11
* Phone model: Samsung SM-G970F (beyond0ltexx)
* Briar version: 1.4.5 (4df523a)
* User feedback: "I tried to login, entered my password and then Briar just crashed. I used this account before. But then I restored my...* Android version: 11
* Phone model: Samsung SM-G970F (beyond0ltexx)
* Briar version: 1.4.5 (4df523a)
* User feedback: "I tried to login, entered my password and then Briar just crashed. I used this account before. But then I restored my phone from the backup I made a month ago."
Log:
```
03-07 19:47:35.275 I/BriarApplicationImpl: Created
03-07 19:47:35.321 I/AccountManagerImpl: Found database key in primary file
03-07 19:47:39.685 I/BaseActivity: Creating SplashScreenActivity
03-07 19:47:39.700 I/BaseActivity: Starting SplashScreenActivity
03-07 19:47:39.702 I/BaseActivity: Resuming SplashScreenActivity
03-07 19:47:40.210 I/BaseActivity: Pausing SplashScreenActivity
03-07 19:47:40.222 I/BaseActivity: Creating NavDrawerActivity
03-07 19:47:40.266 I/BaseActivity: Starting NavDrawerActivity
03-07 19:47:40.270 I/BaseActivity: Resuming NavDrawerActivity
03-07 19:47:40.270 I/BriarActivity: Not signed in, launching StartupActivity
03-07 19:47:40.277 I/BaseActivity: Pausing NavDrawerActivity
03-07 19:47:40.282 I/BaseActivity: Creating StartupActivity
03-07 19:47:40.288 I/AccountManagerImpl: Found database key in primary file
03-07 19:47:40.289 I/BaseActivity: Starting StartupActivity
03-07 19:47:40.303 I/BaseActivity: Resuming StartupActivity
03-07 19:47:40.394 I/BaseActivity: Stopping NavDrawerActivity
03-07 19:47:40.803 I/BaseActivity: Stopping SplashScreenActivity
03-07 19:47:40.804 I/BaseActivity: Destroying SplashScreenActivity
03-07 19:47:47.649 I/AccountManagerImpl: Found database key in primary file
03-07 19:47:48.424 I/AndroidKeyStrengthener: Loaded key from keystore
```
Stacktrace:
```
java.lang.RuntimeException: java.security.InvalidKeyException: Keystore operation failed
at org.briarproject.briar.android.AndroidKeyStrengthener.strengthenKey(AndroidKeyStrengthener.java:101)
at org.briarproject.bramble.crypto.CryptoComponentImpl.decryptWithPassword(CryptoComponentImpl.java:412)
at org.briarproject.bramble.account.AccountManagerImpl.loadAndDecryptDatabaseKey(AccountManagerImpl.java:214)
at org.briarproject.bramble.account.AccountManagerImpl.signIn(AccountManagerImpl.java:200)
at org.briarproject.briar.android.login.StartupViewModel.lambda$validatePassword$0(StartupViewModel.java:112)
at org.briarproject.briar.android.login.StartupViewModel.$r8$lambda$5aurY1rQupylNVXCUST5DjfL1L4(Unknown Source:0)
at org.briarproject.briar.android.login.StartupViewModel$$ExternalSyntheticLambda0.run(Unknown Source:4)
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:923)
Caused by: java.security.InvalidKeyException: Keystore operation failed
at android.security.KeyStore.getInvalidKeyException(KeyStore.java:1383)
at android.security.KeyStore.getInvalidKeyException(KeyStore.java:1393)
at android.security.keystore.KeyStoreCryptoOperationUtils.getInvalidKeyExceptionForInit(KeyStoreCryptoOperationUtils.java:54)
at android.security.keystore.AndroidKeyStoreHmacSpi.ensureKeystoreOperationInitialized(AndroidKeyStoreHmacSpi.java:184)
at android.security.keystore.AndroidKeyStoreHmacSpi.engineInit(AndroidKeyStoreHmacSpi.java:101)
at javax.crypto.Mac.chooseProvider(Mac.java:443)
at javax.crypto.Mac.init(Mac.java:513)
at org.briarproject.briar.android.AndroidKeyStrengthener.strengthenKey(AndroidKeyStrengthener.java:98)
... 9 more
Caused by: android.security.KeyStoreException: Invalid key blob
at android.security.KeyStore.getKeyStoreException(KeyStore.java:1306)
... 16 more
```Android 1.4https://code.briarproject.org/briar/briar-desktop/-/issues/367gradle.properties defines org.gradle.jvmargs twice2022-06-13T08:56:13ZSebastiangradle.properties defines org.gradle.jvmargs twiceWhile working on !8 I noticed it reverts a commit that introduces this issue (2e2b0f15153316)While working on !8 I noticed it reverts a commit that introduces this issue (2e2b0f15153316)https://code.briarproject.org/briar/briar-desktop/-/issues/366Improve screen-reader support2023-04-17T22:04:24ZMikolai GütschowImprove screen-reader supportTargeting issues raised in #341 and as part of #84.
- Heading structure: > not supported by upstream Compose (https://github.com/JetBrains/compose-jb/issues/2119)
- [ ] "Welcome to Briar" on login and main screen (no chats)
- [ ] co...Targeting issues raised in #341 and as part of #84.
- Heading structure: > not supported by upstream Compose (https://github.com/JetBrains/compose-jb/issues/2119)
- [ ] "Welcome to Briar" on login and main screen (no chats)
- [ ] contact name in chat screen
- [ ] "Settings" on SettingsScreen
- Image(Button) contentDescription:
- [ ] Briar logo on login > only of decorative nature, automatically skipped over by VoiceOver
- [x] back and info button on login > !223 and info button already "About Briar Desktop" on `main`
- [x] menu button in chat screen > already "Show Contact Menu" on `main`
- [x] add contact button without chats > fixed on `main`
- [x] attachment button in chat screen > fixed on `main`
- Missing context:
- [x] show password buttons on login/change password > automatically grouped on macOS/VoiceOver
- [x] labels for text fields (registration screen) > !225
- Missing list grouping:
- [x] contact list > !218
- [x] settings as list > !224
- Missing state information (expanded/collapsed): Dropdowns/Pop-Ups not supported by Compose https://github.com/JetBrains/compose-jb/issues/2185
- [ ] menu button in chat screen
- [ ] theme/language settings, also dynamic changes
- Misc:
- [ ] error message on login (not read out loud) > upstream bug: https://github.com/JetBrains/compose-jb/issues/2277
- [x] about dialog (no exit button, table not marked as such, email is not link) > !221
- [x] message count/online status in contact list > !218
- [x] "keyboard trap" in compose message text field (tab button is stuck in text field) > !222
- [ ] Missing landmarks on MainScreen to convey structure to screen-reader user > not supported by Compose
- [x] Keyboard focus does not go to close button on add contact dialog > probably missing OS-functionality on Ubuntu/Orca which is anyhow not supported, confirmed to work on macOS with VoiceOver as expected
- [ ] Dropdown not marked as such (settings) > Dropdowns/Pop-Ups not supported by Compose https://github.com/JetBrains/compose-jb/issues/2185
- [x] Briar link name/label on Add Contact dialog > !230
- [x] Add attachment button not keyboard-focusable on macOS > !222Mikolai GütschowMikolai Gütschowhttps://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/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/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.