This one is odd.
I find that if I
- Add an image to a post
- Set a caption on the image
- Tap the caption dialog to bring up the keyboard
- Tap the navbar (very easy to do by accident while typing, just tap
under the spacebar)
The caption dialog disappears and you lose your caption.
(This doesn't happen in ANY other dialog in the app, and in the caption
dialog it ONLY happens when the keyboard is up.)
I got a tablet and on the tablet this happens ALL THE TIME.
I was considering adding a "really cancel?" dialog to the caption
dialog. But then I discovered (thank you @memorion@mastodon.social) by
setting getCanceledOnTouchOutside(false), I could make the bad behavior
go ahead completely. In my tests now I can only make the dialog go away
by tapping the actual back button.
I believe the potential negative impact of this is low because the
caption dialog is full screen, so it was already impossible to trigger
the touch outside behavior on *purpose*.
I might attempt a "really cancel caption?" dialog later because it sucks
to lose a long caption you have typed, but I think this fixes my
personal problem by itself.
---------
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
```
android.database.sqlite.SQLiteConstraintException: FOREIGN KEY constraint failed (code 787 SQLITE_CONSTRAINT_FOREIGNKEY)
at android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId(Native Method)
at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId(SQLiteConnection.java:961)
at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId(SQLiteSession.java:790)
at android.database.sqlite.SQLiteStatement.executeInsert(SQLiteStatement.java:89)
at androidx.sqlite.db.framework.FrameworkSQLiteStatement.executeInsert(FrameworkSQLiteStatement.kt:42)
at androidx.room.EntityInsertionAdapter.insertAndReturnId(EntityInsertionAdapter.kt:101)
at com.keylesspalace.tusky.db.dao.TimelineStatusDao_Impl$insert$2.call(TimelineStatusDao_Impl.kt:345)
at com.keylesspalace.tusky.db.dao.TimelineStatusDao_Impl$insert$2.call(TimelineStatusDao_Impl.kt:340)
at androidx.room.CoroutinesRoom$Companion.execute(CoroutinesRoom.kt:56)
at com.keylesspalace.tusky.db.dao.TimelineStatusDao_Impl.insert(TimelineStatusDao_Impl.kt:340)
at com.keylesspalace.tusky.components.notifications.NotificationsRemoteMediator.replaceNotificationRange(NotificationsRemoteMediator.kt:169)
at com.keylesspalace.tusky.components.notifications.NotificationsRemoteMediator.access$replaceNotificationRange(NotificationsRemoteMediator.kt:36)
at com.keylesspalace.tusky.components.notifications.NotificationsRemoteMediator$load$3.invokeSuspend(NotificationsRemoteMediator.kt:109)
at com.keylesspalace.tusky.components.notifications.NotificationsRemoteMediator$load$3.invoke(Unknown Source:8)
at com.keylesspalace.tusky.components.notifications.NotificationsRemoteMediator$load$3.invoke(Unknown Source:2)
at androidx.room.RoomDatabaseKt$withTransaction$transactionBlock$1.invokeSuspend(RoomDatabaseExt.kt:62)
at androidx.room.RoomDatabaseKt$withTransaction$transactionBlock$1.invoke(Unknown Source:8)
at androidx.room.RoomDatabaseKt$withTransaction$transactionBlock$1.invoke(Unknown Source:4)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:61)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:163)
at kotlinx.coroutines.BuildersKt.withContext(Unknown Source:1)
at androidx.room.RoomDatabaseKt$startTransactionCoroutine$2$1$1.invokeSuspend(RoomDatabaseExt.kt:103)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:277)
at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:95)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:69)
at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source:1)
at androidx.room.RoomDatabaseKt$startTransactionCoroutine$2$1.run(RoomDatabaseExt.kt:99)
at androidx.room.TransactionExecutor.execute$lambda$1$lambda$0(TransactionExecutor.kt:36)
at androidx.room.TransactionExecutor.$r8$lambda$FZWr2PGmP3sgXLCiri-DCcePXSs(Unknown Source:0)
at androidx.room.TransactionExecutor$$ExternalSyntheticLambda0.run(D8$$SyntheticClass:0)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at java.lang.Thread.run(Thread.java:1012)
```
It looks kinda weird because "x just posted" has a different user than
the actual post, but it works for groups I guess? And definitely better
than crashing.
<img
src="https://github.com/user-attachments/assets/8110ff17-674d-4f36-8df0-453a666856a6"
width="320"/>
closes#4563
closes#4631closes#4629
and other weirdness introduced in Tusky 26.1.
I did a lot of testing on 2 physical devices and multiple emulators. It
definitely is better than before, but probably still not perfect.
Adds feature if user clicks on toolbar, on the pages box, or on the tabs
buttons that the keyboard will minimize and focus will be taken off of
search bar.
Further addresses issue #4573
Currently translated at 99.3% (647 of 651 strings)
Translated using Weblate (Occitan)
Currently translated at 98.3% (640 of 651 strings)
Co-authored-by: Quentí <quentinantonin@free.fr>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/oc/
Translation: Tusky/Tusky
This fixes a bug where the timeline would jump to the position of a
previously clicked "load more" when new post are inserted at the top
after swiping to refresh.
This only happens when "Reading order" is set to "Oldest first".
The problem is that updateReadingPositionForOldestFirst (which consumes
the marker to which it should jump) is called from onItemRangeInserted.
But onItemRangeInserted is not called everytime a "load more" is
clicked, leaving the marker active, causing a jump the next time
onItemRangeInserted is called.
I am not sure this fixes all cases of the various jumping bugs that have
been reported recently as this was the only one I could reliably
reproduce.
Related to https://github.com/tuskyapp/Tusky/issues/4493
I don't know why exactly, but when the ViewHolder gets recycled and the
ProgressBar is set to visible again, it just doesn't show anything. It
seems to be a bug in the platform ProgressBar, and it doesn't happen on
all devices. Replacing it with a CircularProgressIndicator fixes the bug
and looks the same.
Reported here:
https://github.com/tuskyapp/Tusky/issues/4493#issuecomment-2182407513
This does 2 things:
- Removes `AccountSwitchInterceptor`, the main culprit for the bug. APIs
can no longer change their base url after they have been created. As a
result they are not Singletons anymore.
- Additionally, I refactored how MainActivity handles Intents to make it
less likely to have multiple instances of it active.
Here is how I could reliably reproduce the bug:
- Be logged in with account A and B
- Write a post with account A, cancel it before it sends (go into flight
mode for that)
- Switch to account B
- Open the "this post failed to send" notification from account A,
drafts will open
- Go back. You are in the MainActivity of account A, everything seems
fine.
- Go back again. You are in the old, now broken MainActivity of account
B. It uses the database of account B but the network of account A.
Refreshing will show posts from A.
closes#4567closes#4554closes#4402closes#4148closes#2663
and possibly #4588
[Let's encrypt had to make some changes to their
signing](https://letsencrypt.org/2023/07/10/cross-sign-expiration.html),
as a result Android 7 doeesn't have the root certificates necessary to
trust Let's encrypt signed certificates anymore. Since most Fedi
instances use Let's encrypt, that is a problem. To work around we can
add the certificates to Tusky directly.
Details [here](https://stackoverflow.com/a/78309587).
closes#4607
Currently translated at 100.0% (651 of 651 strings)
Translated using Weblate (German)
Currently translated at 99.8% (650 of 651 strings)
Co-authored-by: Connyduck <weblate@connyduck.at>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/de/
Translation: Tusky/Tusky
This will make it less likely that data from different accounts will get
mixed up.
I checked the codepaths and we shouldn't hit viewModel if account is not
there but this is still a bit of risk to assume that so I'll investigate
if we can pass in more things and use DI to make it more secure
---------
Co-authored-by: Conny Duck <git@connyduck.at>
Addresses issue #4573. Updates searchView in SearchActivity to clear
focus when a user makes a search. This allows the keyboard to not keep
popping up after a user goes back to search screen after clicking on a
searched item.
This is the third attempt to fix `RequestBuilder.submitAsync()`. For the
rationale, see the comments of #4436.
We now clear the continuation reference after resuming it, to make sure
that:
1) It will only be resumed once
2) It will not leak the coroutine when Glide keeps the `Request` around.
Without the `isPersistent = false` flag the preference is saved to
SharedPreferences in addition to the account and overrides the shown
value. So it would always show the value of the last account it was set
to. It was working fine though, only the shown value was wrong.
https://social.sitedethib.com/@Claire/112769984398891581
https://social.froonix.org/@cs/112767747835228296
We were caching the instance info with the instance name as the key and
then look it up with the actual domain and those do not always match so
the check if translation is supported fails. fnx.li vs
social.froonix.org in this case.
re: https://infosec.exchange/@webhat/112745609655586468
Boost were not correctly handled here, probably because they are only on
profile timelines which I rarely check. This makes sure likes and boosts
get correctly set to posts even when they are boosts.