IOS client consistently hangs when writing new post at ~= 150 chars

[jakemanion]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

1. Start new post or reply
2. Start writing
3. App consistently hangs when about 150 characters have been typed.
4. App needs a restart to do anything else

The hang is odd - the carat is still flashing, but the keyboard gets stuck as per the attached image, and nothing is interactable.

Expected Behavior

It should allow writing until the full character limit

Steps To Reproduce

1. On Mastodon for iOS v1.4.7 (199) on iPhone SE A2783 running iOS 15.4.1 (19E258)
2. Start new post or reply
3. Start writing until about150 characters

Environment

- Device: iPhone SE A2783
- OS: 15.4.1 (19E258)
- Version: Mastodon for iOS v1.4.7
- Build: 199

Anything else?

No response

[LorenAmelang]

Happens to me, too. "The Mastodon iOS app locked up every try when the count hit exactly 400! Had to be hard killed."

Again today:

iOS 16.1.1, Mastodon 1.4.7 (199)

Is there any evidence I could collect and share?

[j-f1]

If you have a Mac with Xcode installed, it would be awesome if you could capture a trace of the hang. Here’s how:

1. Open Xcode
2. Plug in your device and open the Mastodon app
3. Select Xcode → Open Developer Tool → Instruments from the menu bar
4. In the window that pops up, select Time Profiler.
5. Select your iOS device in the left menu next to “Choose a profiling template for” and then choose the Mastodon app from the Running Applications section of the right menu. (It should have a number after its name, you can ignore the number)
6. Click Choose.
7. Click the record button in the top left.
8. On your iPhone, reproduce the hang.
9. Click the stop button in the top left after the hang has been happening for at least a few seconds.
10. Save and upload the trace file.

This will help understand what code is running when you encounter the hang.

[LorenAmelang]

Sorry, no Mac here. Linux, Windows, iPad with Playgrounds, a-Shell and iSH...

[jaredkrinke]

This happens consistently to me as well on an iPhone SE (3rd gen). Is there any way to capture a trace or logs without a Mac that would be helpful?

[ObviousDWest]

Me too. Twice on a new post at exactly the same position. And once doing a reply. For your enjoyment:

[ObviousDWest]

For me, this is caused by Display Zoom/Use Larger text in iOS settings. Disabling that makes longer posts possible. Reenabling it, I got the crash/hang again in about the same place. This is a newer iPhone SE.

[jaredkrinke]

I have (and have always had) that setting disabled, and I still consistently hit this hang on iPhone SE 3rd gen.

[jaredkrinke]

One thought: most of the reports here mention iPhone SE, and one mentions a "larger text" setting. Is there any chance this could be related to small screens or a small screen-to-font-size ratio?

[j-f1]

If any of you have a Mac and are willing to temporarily install Xcode, my instructions in #705 (comment) would provide debugging info that would be super helpful for sorting out exactly why things are breaking.

[thespianuk]

If any of you have a Mac and are willing to temporarily install Xcode, my instructions in #705 (comment) would provide debugging info that would be super helpful for sorting out exactly why things are breaking.

Hi - have a trace here after replicating the issue - can you provide an alternative way of sharing this with the Mastodon App Devs and I'll send it across and am happy to provide anything else you need. I'm on mastodon.social as @marksemczyszyn

[j-f1]

Thanks to @thespianuk’s trace, I’ve been able to track down the issue!

The relevant code seems to be at…

mastodon-ios/MastodonSDK/Sources/MastodonUI/Scene/ComposeContent/ComposeContentViewModel+DataSource.swift

Lines 36 to 48 in 3e2282c

	$contentCellFrame
	.map { $0.height }
	.removeDuplicates()
	.sink { [weak self] height in
	guard let self = self else { return }
	guard !tableView.visibleCells.isEmpty else { return }
	UIView.performWithoutAnimation {
	tableView.beginUpdates()
	self.composeContentTableViewCell.frame.size.height = height
	tableView.endUpdates()
	}
	}
	.store(in: &disposeBag)

It seems like changing the composeContentTableViewCell frame may cause SwiftUI to re-layout and update the contentCellFrame height. One solution could be to do some filtering here to reduce the risk of an issue like this. Another solution could be dropping the UITableView being used here in favor of a fully SwiftUI view hierarchy (possibly with the scrolling handled by a UIScrollView because manually adjusting the scroll position of a ScrollView has caused me so. much. pain. in the past)

[ridgekuhn]

I'm also experiencing this issue on iPhone SE w iOS 15.7.1 and Mastodon app 1.4.9 build 224. Unfortunately, my Mac is on Catalina and the latest XCode I can run atm is v12, which doesn't seem to be able to profile my updated iPhone. Is there any other info I can provide that might help?