Fix crash: infinite layout loop in timeline with media/reactions

[beezly]

Problem

Opening a room containing video/image messages with reactions or read receipts causes an infinite layout loop that crashes the app with NSGenericException:

The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window.

The crash is timing-dependent — it reproduces when launched normally but not always under a debugger.

Root Cause

NSHostingView inside NSTableView with usesAutomaticRowHeights enters an infinite constraint update cycle. During layout, NSHostingView.layout() flushes SwiftUI transactions, which can invalidate constraints (especially when the SwiftUI view tree structure changes), which re-enters layout — exceeding AppKit's re-entrancy limit.

The crash was latent since the NSTableView rewrite (#47). Adding view complexity (reactions, read receipts, video playback) increased the likelihood of triggering the loop.

Fix

Four commits, each addressing a contributing factor:

1. Guard against zero width/height in image aspect ratio

Prevent division by zero when image metadata reports zero or missing dimensions, which produces infinity/NaN aspect ratios.

2. Video sizing fixes

• Same zero-division guards as images
• Correct modifier order: .aspectRatio() before .frame(maxHeight:)
• Add minHeight for videos without thumbnails (otherwise MatrixImageView renders a zero-intrinsic-size rectangle that collapses under .aspectRatio(.fit))

3. Stabilise view tree in MessageEventBodyView

Replace conditional if/else if blocks for reactions and read receipts with an always-present HStack that uses frame(height: 0) + .clipped() when empty. Conditional view branches change the SwiftUI view tree structure when data loads asynchronously, triggering invalidateIntrinsicContentSize during layout.

4. Replace usesAutomaticRowHeights with deferred self-sizing

SelfSizingHostingView subclass that:

• Sets sizingOptions = [] to opt out of Auto Layout constraint solving
• Overrides invalidateIntrinsicContentSize() to schedule a coalesced async height update instead of calling super (which would re-enter the constraint system)
• measureHeight() temporarily re-enables sizing, pins a width constraint, reads fittingSize, then resets — all outside the layout pass
• Row heights are cached and updated via noteHeightOfRows with animation disabled

Also removes the old measurementHostingView (separate NSHostingController per height query) and handleTableResize observer.

[beezly]

I've based this commit off #80 as it includes changes to similar code. It should show the same two commits as 80 until that branch is merged, and then should just have the last four.

[viktorstrate]

Bugs found when testing it

• When I clicked play on a video, the video player became very small.

  

• It doesn't seem to handle wrapping properly. Even after loading a room from scratch (no resizing after timeline load) can this happen.

• By resizing the window to a small width, I managed to hit an infinite loop, when pausing the debugger, I placed in the sizeThatFits function. I'm not sure this is related to this PR and it might as well be an unrelated old bug.

  

Comments

I think the layout of the timeline is very complicated, so I think we need to approach this problem very carefully. I am suspecting that commit 4 is the one causing the rows to have the wrong height, since it's the only one that touches the AppKit level layouting. And that commit 1-3 could be standalone improvements independent of 4.

If it's easier we can split this PR up into 1-3, make sure they fully work and merge them, and then we can focus on improving the AppKit layout in a separate PR. What do you think?

[beezly]

No problem! I'll make take 4 out of this PR and put it's on it's own and see if that fixes the problems you found.

…

On Tue, 17 Mar 2026, 08:17 Viktor Strate Kløvedal, ***@***.***> wrote: *viktorstrate* left a comment (viktorstrate/mactrix#84) <#84 (comment)> Bugs found when testing it - When I clicked play on a video, the video player became very small. Screenshot.2026-03-17.at.09.00.07.png (view on web) <https://github.com/user-attachments/assets/f28d1d70-c56e-45ab-9cba-089997bbdeff> - It doesn't seem to handle wrapping properly. Even after loading a room from scratch (no resizing after timeline load) can this happen. Screenshot.2026-03-17.at.09.05.52.png (view on web) <https://github.com/user-attachments/assets/c3958a2a-d5af-4b49-843b-bd0f85fa037d> - By resizing the window to a small width, I managed to hit an infinite loop, when pausing the debugger, I placed in the sizeThatFits function. I'm not sure this is related to this PR and it might as well be an unrelated old bug. Screenshot.2026-03-17.at.09.05.05.png (view on web) <https://github.com/user-attachments/assets/f07a526a-0abf-4a3d-868f-4a91555a2f00> Comments I think the layout of the timeline is very complicated, so I think we need to approach this problem very carefully. I am suspecting that commit 4 is the one causing the rows to have the wrong height, since it's the only one that touches the AppKit level layouting. And that commit 1-3 could be standalone improvements independent of 4. If it's easier we can split this PR up into 1-3, make sure they fully work and merge them, and then we can focus on improving the AppKit layout in a separate PR. What do you think? — Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACYYG7BVSZATJSX3OKO65L4RECZZAVCNFSM6AAAAACWT35DZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANZTGE2DAMJUGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[beezly]

I ran a test build of this and wrapping is correct.