Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attachments, images and custom emoji loading very slow on iOS #8159

Open
TorbenCapiau opened this issue Aug 21, 2024 · 9 comments
Open

Attachments, images and custom emoji loading very slow on iOS #8159

TorbenCapiau opened this issue Aug 21, 2024 · 9 comments

Comments

@TorbenCapiau
Copy link

TorbenCapiau commented Aug 21, 2024

Summary

Lately images, attachments and custom emojis are loading very slow in the mobile app on iOS + phone heats up in the process.

Environment Information

  • Device Name: iPhone 14
  • OS Version: iOS 17.5.1
  • Mattermost App Version: 2.19.0
  • Mattermost Server Version: 9.11

Steps to reproduce

Normal usage of iOS mobile app is enough.

Expected behavior

Images and attachments to load instantly.

Observed behavior (that appears unintentional)

I did some investigation and this is my conclusion:

The below has been confirmed by multiple iOS users on the latest version

  • App has blurred thumbnails for recent images which show instantly (as expected)
  • App does eventually request the image from the server. Server response is fine (measured overall request / response time with Nginx logging).
  • Overall loading an image, emoji, attachment easily takes 5-10 seconds or more
  • My phone is heating up when scrolling through chat history with multiple images

The above and especially the heating up of my phone makes me believe that there is some issue with looking up assets in local cache. Obviously this also has an effect on battery. To me it looks like the lookup in local cache is somehow locked / stuck in a loop for those 5-10 seconds, after which the app realizes the asset is not in cache, requests it from the server and eventually displays it fine.
I have completely deleted the app and reinstalled (effectively clearing the on-device cache) but this had no effect. The issue returned immediately.

Worth mentioning that there is no issues at all with web client both on mobile and desktop, which to me means this is a mobile specific issue and not server-related.

While I do not have an Android phone myself, I've been told this behavior does not happen on Android.

Possible fixes

I haven't looked into the code yet. I can mention that while I feel like the iOS app has always had it's fair bit of issues in the past, this specific issue definitely got (way) worse since the last update.

Happy to provide additional information or specific logs if needed. Thanks.

@TorbenCapiau
Copy link
Author

Looking into the latest release notes for package changes around images, probably related:
https://docs.mattermost.com/about/mobile-app-changelog.html#open-source-components

@amyblais
Copy link
Member

Added notes at https://mattermost.atlassian.net/browse/MM-58678.

@amyblais amyblais added the Bug Report/Open Bug report/issue label Aug 21, 2024
@TorbenCapiau
Copy link
Author

Added notes at https://mattermost.atlassian.net/browse/MM-58678.

Thanks, but I believe this is not necessarily related. I had seen the issue under MM-58678 before opening mine, but there we are talking about <1 second delay (which to me has always been normal behavior). The issue was also created before the release of 2.19 - while this issue for me has only started as of 2.19.

Did some further investigation. Attached is a video which shows that loading an image takes 40+ seconds (!)
The app also somewhat locks up while loading images. For example pasting text is no longer possible (it just hangs). To me this is quite an app-breaking bug.

RPReplay_Final1724249150.mov

Also, out of proportion battery usage while testing:
IMG_0880
IMG_0879

I have ran the 2.19 release branch locally on an emulator and there it is working fine, also the app works fine on my iPad. Both my Macbook and iPad are using a M1 processor, so I suspect that the M1 can handle whatever CPU load the app demands to load an image, but not my iPhone's A15.

If you want to replicate, I'd suggest to test on your end on a regular (non-pro) iPhone and not inside emulators.

@AlexanderVanlancker
Copy link

I am having the same issue after updating the app. I think it is related to thereact-native-fast-image getting replaced withexpo-image

@amyblais
Copy link
Member

Opened https://mattermost.atlassian.net/browse/MM-60251.

@TorbenCapiau
Copy link
Author

Thought I'd provide an update:
Not sure why I hadn't thought of it before, but after joining the community server I noticed that images are loading fine there.
Figured something has to be wrong with my setup but I have not been able to pin-point it yet.

In a completely new, empty instance hosted by myself using mattermost/docker, I do not encounter the same issue. However, after attaching a copy of my existing database and data folder (but keeping the new config.json), the issue re-appears.

I am now trying a Workspace Migration. It looks like it may take some time so will report back when it finished.

@larkox
Copy link
Contributor

larkox commented Aug 22, 2024

@TorbenCapiau Let us know if you get anything difference, so we can look into it.

One of my theories is that there is something in your data that is hitting some blindspot, and causes some kind of re-rendering loop. That would explain why it happens to you when you use your data, but not in community or the empty instance.

But if that is the case, we would need to find out what is the piece of data that is causing the app go haywire.

@amyblais amyblais removed the Bug Report/Open Bug report/issue label Aug 22, 2024
@TorbenCapiau
Copy link
Author

@TorbenCapiau Let us know if you get anything difference, so we can look into it.

One of my theories is that there is something in your data that is hitting some blindspot, and causes some kind of re-rendering loop. That would explain why it happens to you when you use your data, but not in community or the empty instance.

But if that is the case, we would need to find out what is the piece of data that is causing the app go haywire.

Yes will do! Indeed would like to pinpoint the cause as well.
I ran into some issues running the default mmctl export command due to a few paths to attachments that went broken. I will develop a script to check the paths and remove the entries to broken paths from my DB before running the export. I hope to work on this tomorrow.

One of my current theories is that it may have something to do with custom emojis, as I see the emoji picker for mobile is being worked on and we have quite the amount of custom emojis on our server (1400+). I'll report back when I get some more insights.

@TorbenCapiau
Copy link
Author

TorbenCapiau commented Aug 24, 2024

@larkox coming back to this. Long story short: there seems to be a bug in custom status messages with custom emojis (as WEBP format?).

I have tried a couple of things:

  • Workspace migration: Same result after inclusion of attachments (and thus also custom emoji)
  • Disable custom emoji altogether: App responds fine again
  • Enable custom emoji, but remove all WEBP images (as I know these tend to cause some issues): Still laggy app

After removing all custom emojis and adding back a few, we noticed no lag. However we were able to replicate the bug by setting a WEBP emoji as custom status message emoji on just one user (who had multiple recent messages). After that, once we start scrolling through the channel history, the app becomes slow again, not loading profile pictures and images.

Still not sure why after removing all WEBP emojis we still had the issue, maybe custom statuses were still cached, causing the app to still crash.

Would be great to hear if you can replicate the issue on your end. I suspect you'll need some back and forth messages between users with at least one of them having a custom status set as described above.

Please let me know in case you need any additional information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants