briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:20Zhttps://code.briarproject.org/briar/briar/-/issues/615Forums: Keyboard stays open2018-06-12T11:32:20ZMegaloxForums: Keyboard stays openI wanted to reply but decided against and left the forums via backarrow. The keyboard stayed open.
![forum_keyboard_bug](/uploads/c417c600e6239e19fb00398080363f01/forum_keyboard_bug.jpg)I wanted to reply but decided against and left the forums via backarrow. The keyboard stayed open.
![forum_keyboard_bug](/uploads/c417c600e6239e19fb00398080363f01/forum_keyboard_bug.jpg)Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/611Body cache in ConversationActivity isn't thread-safe2018-06-12T11:32:20ZakwizgranBody cache in ConversationActivity isn't thread-safeChanges to ConversationActivity in June broke the thread-safety of the body cache. If it's going to be accessed from the UI and DB threads it should be a `final ConcurrentHashMap<MessageId, byte[]>` rather than a `volatile HashMap<Messag...Changes to ConversationActivity in June broke the thread-safety of the body cache. If it's going to be accessed from the UI and DB threads it should be a `final ConcurrentHashMap<MessageId, byte[]>` rather than a `volatile HashMap<MessageId, byte[]>`.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/610Result handlers can return results to destroyed activities/fragments2018-06-12T11:32:20ZakwizgranResult handlers can return results to destroyed activities/fragments@grote spotted this problem in !276, but it could happen anywhere a `ResultHandler` or `ResultExceptionHandler` is used. The activity or fragment that created the handler may be destroyed before the result or exception is handled.@grote spotted this problem in !276, but it could happen anywhere a `ResultHandler` or `ResultExceptionHandler` is used. The activity or fragment that created the handler may be destroyed before the result or exception is handled.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/609Update UI in paused state to support multi-window mode2018-01-28T11:30:28ZakwizgranUpdate UI in paused state to support multi-window modeIn Android N's multi-window mode, the app that doesn't have focus is in the paused state. We should move all our calls to register/unregister event handlers, refresh content, etc, from onPause/onResume to onStart/onStop so that the UI is...In Android N's multi-window mode, the app that doesn't have focus is in the paused state. We should move all our calls to register/unregister event handlers, refresh content, etc, from onPause/onResume to onStart/onStop so that the UI is updated in the paused state.
https://developer.android.com/guide/topics/ui/multi-window.htmlMilestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/607Don't clear lists in onPause()2018-06-12T11:32:20ZakwizgranDon't clear lists in onPause()Various activities and fragments clear their lists in onPause() and asynchronously repopulate them in onResume(). This results in the appearance of the list briefly changing as the user navigates away.
For lists where items are never ...Various activities and fragments clear their lists in onPause() and asynchronously repopulate them in onResume(). This results in the appearance of the list briefly changing as the user navigates away.
For lists where items are never removed, we can leave the list populated in onPause() and asynchronously add any new items in onResume(). This will allow the views for existing items to be recycled.
For lists where items can be removed while the activity/fragment is paused, we'll need another solution. Clearing and then asynchronously repopulating the list in onResume() may result in the old contents being briefly visible, then disappearing, then the new contents appearing. Asynchronously loading the new contents in onResume() and then replacing the old contents (using a batched update to avoid flicker) may be acceptable as long as we gracefully handle any attempts to interact with items that are due to be removed.
See discussion on !276.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/605Add database method for retrieving a contact by local and remote author IDs2018-06-12T11:32:20ZakwizgranAdd database method for retrieving a contact by local and remote author IDsMilestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/599Fetch RSS feeds via Tor2018-06-12T11:32:20ZakwizgranFetch RSS feeds via TorUse the localhost Socks proxy to fetch the feeds. The proxy port is currently set in briar-android and would need to be moved to core or api.
The `FeedManager` should listen to `TransportEnabledEvent`s and enable the feed fetching sch...Use the localhost Socks proxy to fetch the feeds. The proxy port is currently set in briar-android and would need to be moved to core or api.
The `FeedManager` should listen to `TransportEnabledEvent`s and enable the feed fetching scheduler when Tor is started first. For simplicity, it should not turn off the scheduler when Tor gets turned off, but let the fetch job fail cleanly when Tor is not running.
We should use stream isolation to ensure the lookups for different feeds happen over different circuits. This is done by specifying a different SOCKS username and password for each feed (any username and password can be used, they just need to be different - generating them on the fly would be fine).Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/598Remove unused code and layouts for old blog implementation2018-06-12T11:32:20ZakwizgranRemove unused code and layouts for old blog implementationIf we decide we need them in future, they'll still be in git.If we decide we need them in future, they'll still be in git.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/589When a message is shared, share its transitive dependencies2018-06-12T11:32:20ZakwizgranWhen a message is shared, share its transitive dependenciesLike other recursive operations on the dependency graph, this should not be done in a single transaction. So we'll need to find and resume any unfinished operations at startup, by looking for shared messages with unshared dependencies.Like other recursive operations on the dependency graph, this should not be done in a single transaction. So we'll need to find and resume any unfinished operations at startup, by looking for shared messages with unshared dependencies.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/586Store latest timestamp and unread count in group metadata for invitations2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for invitationsThe contact list loads all invitation messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every message, which in the wors...The contact list loads all invitation messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every message, which in the worst case iterates over all sessions. Store this information in the group metadata and expose it through the SharingManager interface.
The timestamp should relate to the latest message that would be visible in the UI, i.e. invitations and responses.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/585Store latest timestamp and unread count in group metadata for introductions2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for introductionsThe contact list loads all introduction messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every introduction message, wh...The contact list loads all introduction messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every introduction message, which in the worst case iterates over all sessions. Store this information in the group metadata and expose it through the IntroductionManager interface.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/584Store latest timestamp and unread count in group metadata for private messaging2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for private messagingThe contact list loads all private message headers just to get the latest timestamp and unread message count for each conversation. Store this information in the group metadata and expose it through the MessagingManager interface.
Rel...The contact list loads all private message headers just to get the latest timestamp and unread message count for each conversation. Store this information in the group metadata and expose it through the MessagingManager interface.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/569Convert HTML to plain text safely and readably2018-06-12T11:32:21ZakwizgranConvert HTML to plain text safely and readablyFor RSS import we need to convert HTML blog posts into plain text while preserving readability, and without allowing any unsafe content to be rendered. For RSS import we need to convert HTML blog posts into plain text while preserving readability, and without allowing any unsafe content to be rendered. Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/560Design a consistent layout for identities2018-06-12T11:32:22ZakwizgranDesign a consistent layout for identitiesThe various bits of information relating to an identity - the avatar, nickname and trust level - are displayed in inconsistent ways throughout the app.
* Contact list: trust level isn't shown, timestamp is below nickname
* Forums: id...The various bits of information relating to an identity - the avatar, nickname and trust level - are displayed in inconsistent ways throughout the app.
* Contact list: trust level isn't shown, timestamp is below nickname
* Forums: identity and timestamp are below content, avatar is 20 dp, timestamp is to the right of all other elements
* Blogs: identity and timestamp are above content, avatar is 30 dp, timestamp is below nickname
Let's decide on a consistent way of presenting this information. My preferred solution would be the one that's currently used for blogs: all elements are shown, the timestamp is shown below the nickname and trust level, if there's content it's shown below the other elements. This would involve the following changes:
* Contact list: show trust level to the right of nickname
* Forums: increase avatar to 30 dp, move timestamp below nickname, move content below identity and timestamp
We should also use the same font sizes for the header and content information in forum and blog posts.Milestone Ehttps://code.briarproject.org/briar/briar/-/issues/556Thread safety and blocking issues in ForumControllerImpl2018-06-12T11:32:22ZakwizgranThread safety and blocking issues in ForumControllerImplMilestone Ehttps://code.briarproject.org/briar/briar/-/issues/554Audit uses of ResultHandler2018-06-12T11:32:22ZakwizgranAudit uses of ResultHandler* Controllers should depend on ResultHandler/ResultExceptionHandler, not UiResultHandler/UiResultExceptionHandler, to allow us to use synchronous handlers when unit testing controllers
* Handlers shouldn't return true if everything went...* Controllers should depend on ResultHandler/ResultExceptionHandler, not UiResultHandler/UiResultExceptionHandler, to allow us to use synchronous handlers when unit testing controllers
* Handlers shouldn't return true if everything went fine or false if there was an exception - use ResultExceptionHandler if the UI needs to know about failures, and ResultExceptionHandler\<Void\> if it doesn'tMilestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/552Check thread safety of MessageTree2018-06-12T11:32:22ZakwizgranCheck thread safety of MessageTreeMilestone Ehttps://code.briarproject.org/briar/briar/-/issues/551IllegalStateException, SettingsFragment not attached to Activity2018-06-12T11:32:22ZakwizgranIllegalStateException, SettingsFragment not attached to ActivityGot this crash several times on the HTC Wildfire S (Android 2.3.3) while navigating in and out of the settings screen:
```
07-29 17:21:52.726 19626-19626/org.briarproject E/ACRA: ACRA caught a IllegalStateException for org.briarproje...Got this crash several times on the HTC Wildfire S (Android 2.3.3) while navigating in and out of the settings screen:
```
07-29 17:21:52.726 19626-19626/org.briarproject E/ACRA: ACRA caught a IllegalStateException for org.briarproject
java.lang.IllegalStateException: Fragment SettingsFragment{40ca1ca8} not attached to Activity
at android.support.v4.app.Fragment.getResources(Fragment.java:636)
at android.support.v4.app.Fragment.getString(Fragment.java:658)
at org.briarproject.android.fragment.SettingsFragment$4.run(SettingsFragment.java:210)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4268)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)
```Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/538Recipient of forum posts offers them back to sender2018-12-19T12:22:56ZakwizgranRecipient of forum posts offers them back to senderWhen syncing forum posts between two devices, the recipient offers each post back to the sender after it is delivered to the client. This causes unnecessary traffic between the two devices. The sync layer should know that the sender has ...When syncing forum posts between two devices, the recipient offers each post back to the sender after it is delivered to the client. This causes unnecessary traffic between the two devices. The sync layer should know that the sender has seen the post and therefore should not offer it.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/532Unread forum post counter is attached to wrong forum2018-06-12T11:32:23ZakwizgranUnread forum post counter is attached to wrong forumAfter creating a forum, adding some posts and returning to the forum list, the forum's unread post counter is a duplicate of a previously existing forum's counter. The counter shows a number of unread posts that's larger than the number ...After creating a forum, adding some posts and returning to the forum list, the forum's unread post counter is a duplicate of a previously existing forum's counter. The counter shows a number of unread posts that's larger than the number of posts in the new forum (see screenshot).
![device-2016-07-27-135546](/uploads/274ace47f01cd27b4fa66a9360923ce8/device-2016-07-27-135546.png)Milestone ETorsten GroteTorsten Grote