getting "Namespace RUNNINGBOARD, Code 0xdead10cc" crashes from time to time, i cannot reproduce that, but it was reported by @dignifiedquire; some logs are in App Store Connect, excerpt

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace RUNNINGBOARD, Code 0xdead10cc
Triggered by Thread:  0

full log - so, there seems sth. wrong with background thread handling, searching for "Namespace RUNNINGBOARD, Code 0xdead10cc" brings up some advices, need to investigate further.

EDIT: to sum up, the issue with 0xdead10cc is that a lock is held on some files (probably sql-database) after the app ~~gets~~ signals to be suspended. reason might be dispatched jobs that are still running for a little moment, we tried to mitigate that by recent commits and to exclude this cause. however, might also be that "shared" usage of the database is the cause, that would be very hard to fix, see discussions wrt share-to-delta.

stats of recent versions:

compared with older stats, we had 700 installations and only 1 crash/7 days (at least after removing sqlx)

ftr, 0xdead10cc was also topic in https://github.com/deltachat/deltachat-ios/issues/1057

I'm testing Delta Chat on my iPad. When I added a contact and sent a message nothing seems to happen. I don't see my own message in Delta Chat and I don't see any change in my IMAP account or the destination account. I'm using fastmail.com.

a once imported backup, that works for some days or hours may be forgotten, resulting in the "welcome" screen shown again.

not sure what the reason is here, initially reported via dm, however, ~~i could meanwhile also reproduce that~~ it also happens to me once.

i've seen that only for encrypted databases yet, however, not sure if that happens also to normal ones.

as similar reports are not present for android/desktop, maybe that is related to ios, maybe getting the secret from the system does not always work or so.

@cyBerta i could debug a bit: somehow the logic seems to think, there is no configured account. the account presented to the "welcome view controller" was actually empty, and there was no other account (accountIds == 1). to be honest, i played around with adding/removing accounts first, adding the same account one time encrypted and another time unencrypted. maybe that mixed up some things - however, that was a bit before the "welcome view controller" was displayed suddenly.

with recent commits, we speed up going back to the chatlist (#1395) and going back to the chat (#1358).

with these great changes, other slow things are more visible now (before, most things were slow :)

• opening a chat, even an empty (!) chat takes at least half a second on an iphone7 - there is no reason for that, esp. an empty chat should be opened instantly.
  but even for chat with thousands of messages, the bottleneck is probably not the core: we log these timings in Wrapper.swift at logger?.info("⏰ getMessageIds: \(diff) s") - that takes noticable time, however, it seems to be always a small fraction of overall timing.

i suggest to add temporary more ⏰-logs and see where really the bottleneck is - might be, we cannot do much or not without reasonable effort, however, that would be good to know.

to make it clear: opening a chat is not super-slow, the mentioned iphone7 is quite old. however, if we can get better here, that would still be nice.

once this is done, we can file an issue to check how the contact-profile opening can be speed up (however, that is even less urgent :).

got this hint from the apple review team when trying to ship 1.6; 1.6 was rejected therefore.

"We discovered one or more bugs in your app when reviewed on iPad running iOS 13.4.1 on Wi-Fi. Specifically, an error message appeared upon logging in, we were unable to access the app. "

might be, that just the testrun address was not working and the error is a "normal" timeout error - with a bad wording.

@Basti do you have an idea where the message comes from?

we should get this reproducible, before submitting again.

No notifications are shown until DC is opened. In standby there is no (push) notifications.

• Device: iphone X
• iOS version: 13.3.1
• Delta Chat version: 1.2.1
• Expected behavior: show notification on locked phone.
• Actual behavior: dont show anything until DC is opened, then the red dot shows if new messages.
• Steps to reproduce the problem:
• Screenshots:
• Logs:

Let me know what logs to collect if needed.

• Operating System (Linux/Mac/Windows/iOS/Android): iOS 14.4.2
• Delta Chat Version: 1.16.0
• Expected behavior: Notification within a minute or two
• Actual behavior: No notification at all on the iPhone for received messages, sent messages are notified at the addressees Android after about 10 minutes.
• Steps to reproduce the problem: Install and test sending and receiving messages.
• Screenshots: none
• Logs:

Running on an Iphone 8. It's important to get notifications. They are enabled in the settings, but no notifications are received. (Works for other apps.) If 10 minutes is the normal time for checking the account, please make it possible to check more frequently. (Might that influence the battery usage very badly?)

i encountered some crashes the last days, all similar to https://gist.github.com/r10s/f88d4305a8cbaf91861b3b0298e60a5f (i have more logs, if needed)

Details:
Name: SIGSEGV signal
Date: 7. Apr 2021 at 03:26:53
Stack trace:
0 DBDebugToolkit 0x0000000104ca71d0 handleSIGSEGVSignal + 88
1 libsystem_platform.dylib 0x00000001f8a25d90 3A71914A-C2A7-3514-B519-DF319E7A6E02 + 28048
2 DcCore 0x0000000105a7e374 sqlite3VdbeExec + 32576
3 DcCore 0x0000000105a42d20 sqlite3_step + 2600
4 DcCore 0x00000001059af230 _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h0d3631d5f7ad68c2E + 4716
5 DcCore 0x00000001059aa160 _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h8c5b78c51826ee8aE + 168
6 DcCore 0x00000001059e65d8 _ZN3std3sys4unix6thread6Thread3new12thread_start17hc2fb1317c6a3263bE + 36
7 libsystem_pthread.dylib 0x00000001f8a33c9c _pthread_start + 288
8 libsystem_pthread.dylib 0x00000001f8a38880 thread_start + 8

there is a pr on sqlx that is also related to fetching, https://github.com/launchbadge/sqlx/pull/1156, might be that issue.

fixes #500

ChatList is now managed by ChatListViewModel.

ChatList registers on ViewModel to listen to changes (such changes occur during search/filtering). ChatList also can trigger a table reload by calling viewModel.refreshData.

The ViewModel holds:

• chatList or 3 sections with SearchResults (updated as the user types):
• chats
• contacts
• messages

The ViewModel provides all relevant data to make UITableViewDelegate/Datasource happy. The cell's data is stored in a class called AvatarCellViewModel which can be used for contacts and chats.

Before this PR ChatListController was a normal UIViewController with a tableView as subview. I turned ChatListController into a UITableViewController, because the scrolling reacts better to Keyboard-events.

Also since SearchResults are grouped in sections, I changed the UITableView-style to .grouped, because it looks a lot better.

I did see no reason to add a SearchBar to ArchivedChatsList, because Archived Chats will appear in the normal search results, and it would have complicated things a lot. Therefor the ArchivedChatList's style is not .grouped.

Issues:

• when active search, tap search result, navigate back, there is a scroll-glitch. (edit: caused by KeyBoard-reapperance).

I have a test account (alice@librechat.net) which works fine in all other settings, but I am not able to login with it anymore on the latest master

11:39:49.303 ❤️ ERROR events.callbackSwift():104 - network: Cannot login as alice@librechat.net.

Response from w017f238.kasserver.com: Unsupported authentication mechanism.

Is the error I get

fixes #682

Implemented classic responsive grid layout to display chat images. The layout (number of columns) can be easily changed.

I struggled with the TimeBuckets a bit, but I think the buckets are accurate. I did not find a translation key for older than month X. So this is currently missing.

Needs further tweaks if we also want to use the Gallery for documents also. I would prefer to have this in a separate issue/PR.

Removing the List-item on PreviewController is possible but not super easy neither. I would like to move this sub-task into a separate ticket (since this PR has become quite large already.).

[UPDATE]: Our core currently doesn't provide any message fetches for "time buckets", so grouping the gallery into time sections is not very easy to achieve, because it would require creating DcMsg-Objects from all available gallery related MessageIds to get the date.

After short discussion with @cyBerta we agreed to handle dates as Telegram (iOS) does for now. This can be changed later if we decide that we want to have time groups. The approach now: While scrolling it shows a centered label with the date of the first visible cell.

I personally like this approach a lot better and the implementation was quite easy and fits nicely with our DcCore.

Also consider section headers in iOS UICollections (what we use in our gallery) are not as easy to implement compared to UITableViews. There is no default label, and no grouping etc. and no default native look.

when tapping the profile of a mailinglist member, at least for some mailinglists, the number shown beside "Images and Videos" and "Files and Private Apps" are way too large. i assume, that these numbers reflect all files of the given type:

when tapping the items, nothing happens. also "Last seen" seems to be wrong, we should maybe just hide all these items

reproducible at least in the mailinglist "Delta Chat Community (🇬🇧EN)".

Trying to figure out the root cause for the weird scroll behavior. This PR is only to discuss possible changes. The reason I started investigating this is #1691. The fix for that issue is fairly simple, see af5cefe, if we take the DC Android as an template. However the weird scrolling down and back up when sending a message always happens now. I will explain a little bit more in the comments.

Generally I've noticed that the scrolling-down and up happens, because the messageInputBar looses it's focus when the user taps on the send button. As a result normally the keyboard would disappear. We mitigate that by re-requesting the focus for the messageInputBar when the messageInputBar's UITextViewDelegate calls back textViewShouldEndEditing(). Normally that is sufficient to keep the keyboard in place, on some devices and OS versions you may see a very small flickering. However the frame size of the UITableView immediately changes and all cells at the bottom get moved for a short moment to the bottom of the screen, before the size frame size regains it's previous size - above the keyboard.

While experimenting and reading on stack overflow for possible solutions I learned that we can use contentInset to avoid the content is dragged down to the bottom of the screen. I vaguely remember we already worked with contentInsets in the past in this controller, but scratched that approach because of other issues we had with it like wrong initialization.

My current idea is - contrary to what we tried in the past regarding contentInsets - to set the content inset only temporarily at the bottom before the keyboard events are thrown / the tableViewFrame changes and reset it as soon as the reload() was done and the new message bubble appeared (but is still hidden below the keyboard).

What's not yet clear to me is if any call to scrollDown would be still necessary after resetting the contentInset, or maybe after animating the contentInset value.

What I can confirm so far is that setting the contentInset in textViewShouldEndEditing (= before the keyboard events are thrown / before the tableViewFrame size changes) indeed prevents the messages being moved down if I comment out scrolling completely.

When a user tries to transfer the device data from the one to another device (to setup the 2. device), Delta Chat fails to run on the second device after the transfer finished.

• things to doublecheck:
• [ ] keychain data
• [ ] shared data between app and share extension
• [ ] database
• [ ] blobs

from nov22 consistency discussions:

• Android always puts the v-mark after contact or group name, and also in profile
• iOS always puts the v-mark on the avatar (group or contact), also in profile
• Desktop puts v-mark on Chat-avatar, and after contact names, and v-mark in group-avatar in the group profile but not in the contact profile

Solution: make all platforms do the same thing, namely show v-mark after contact and group names, also in profiles and add a add a byline "verified" (later ""verified by ...") to the profiles.

This also solves the visual conflict between "online" and v-marks.

cmp. https://github.com/deltachat/deltachat-desktop/issues/3035, https://github.com/deltachat/deltachat-core-rust/issues/3786

If I have an external keyboard plugged in over USB, I can't see the lowest part of the most recent message. I can pull it up temporarily to read it, but as soon as I let go, it snaps back. Most importantly, I can not follow links in there.

ask for chat to send it in, maybe it's possible to reuse the share or forward dialog?

I think we can offer previews for the files, so I would say we should show the webxdc's icon there if it's not too complicated, or just show the default webxdc icon for now, so they at least look a bit distinct from the blank default file icon.