Bubble animation overshoots when you send a message.

[ara4n]

Steps to reproduce

1. Send a message. (This video slowed down 3x, with a frame count in the top left to help identify frames):

oversteer.mp4

2. Note that the newly sent bubble animates in nicely from the bottom, sliding into its destination position at frame 34 without overshooting.
3. Note also that the day separator in the timeline also animates roughly in sync with this and doesn't overshoot its stopping place.
4. However, two things go wrong with the timeline's existing msg bubble's animation as it slides upwards:

• It appears to overshoot its destination position - and starting at frame 33 (and finishing at frame 40) it moves downwards. This is particularly obvious as the gap closes between the upper and lower bubbles. This is out of sync with the animation of (say) the day separator in the timeline, making the bubble animation feel inconsistent and as if the bubble somehow has some elasticated inertia connecting it to the timeline (like iMessage's bubbles) - which is surely not the intention.
• The send receipt of the existing bubble unexpectedly pops into view at around 30% opacity in frame 36 and then fades away (compare frame 35 and 36 to see it pop).

It looks as if something is going wrong with the animation for removing the send receipt of the existing message, which in turn causes the appearance of the overshoot animation of the existing bubble.

It's also worth noting that the bottom-right corner of the existing message pops from being rounded to right-angle on frame 17, although that's nothing like as noticeable. (Still, if it could be tweened, it'd certainly look prettier, if only subliminally).

Literally every time I send a message my eye gets grabbed by the overshooting animation, and while it's a relatively minor cosmetic blemish, it's on the critical path of every message you send, so it stacks up over time. I promised myself not to file a bug on it until more important things had been addressed... but thought it's now high time to get it on the radar.

Outcome

What did you expect?

The contents of the timeline should all animate upwards in sync with each other when a new message is sent.

That means that existing send receipts should be hidden by the new bubble coming in over the top of them (as happens today), and then be removed without causing further vertical shifts.

What happened instead?

Instead, something weird is happening where existing send receipts pop in at a higher z-index, while fading out, and seemingly cause the bubble they're associated with to oversteer in its animation and then drift downwards once the SR has faded away.

Your phone model

iPhone 12 Pro Max

Operating system version

iOS 18.5

Application version

921

Homeserver

matrix.org

[ara4n]

I spent Eurovision stabbing at this and got a fix that seems to work: #4128

ScreenRecording_05-18-2025.00-30-03_1.MP4

[ara4n]

(unfortunately i then uncovered #4129 while fixing this, thinking at first it was a regression I'd caused. it was not.)

[ara4n]

So the fix i've proposed does seem to uncover a few more issues:

1. the topmost visible bubble often blinks out of existence abruptly when you insert a new row at the bottom. this already happens without my patch - it's not a regression.
2. when backpaginating in, the bubbles also bounce around and overshoot. again, this isn't a regression, it already happens today.
3. intermittently, the SR abruptly disappears in the bottommost row as soon as the new row is inserted, causing a nasty timeline jump. This is reproduceable if you scroll up and down a few pages to force the bottommost bubble's View to reload (presumably due to cell reuse), and looks like this (yellow shows my new Spacers; purple shows the TimelineItemStatusView, for debugging purposes)

output.mp4

My guess is that this is a nasty race due to the UITableView row-insertion animation clashing with the SR-hiding animation as the TimelineItemStatusView transitions out - and indeed, if I hack around with TimelineItemStatusView to delay hiding the TimelineDeliveryStatusView by even 10ms, i can't reproduce the glitch any more. The animation also looks a bit nicer, as previously the SR block could disappear abruptly in other ways too due to the same race. It looks like this:

output.mp4

I think this vid may also show failure mode 1 at frame 313, as the topmost bubble shoots out of sight. This is presumably another facet of UITableView interacting badly with the resizing SwiftUI View bubble

[ara4n]

2. when backpaginating in, the bubbles also bounce around and overshoot. again, this isn't a regression, it already happens today.

And this is what that looks like (with some really bad dropped frames at the beginning while loading the scrollback):

output.mp4

[ara4n]

Right, for the "overshoot when backpaginating", this looks to be simply caused by the topmost bubble in any sequence having a bunch of padding/spacing at the top (messageBubbleTopPadding) which slowly animates away whenever it's no longer at the top of a sequence. While this is okay, we need the bubble to be bottom-aligned, not top-aligned so it doesn't drift in its cell while that happens (much as the original problem was fixed by top-aligning). Or, disable the View animation when backpaginating, which is probably a good idea too in terms of scroll jumps and/or fighting between UITableView and SwiftUI animations.

[ara4n]

3b2f427 disables animations when changing messageBubbleTopPadding - fixing loading scrollback, but breaking other stuff, including the send-message animation and ability to load image thumbnails :| So this needs more thought.

Meanwhile, the

1. the topmost visible bubble often blinks out of existence abruptly when you insert a new row at the bottom. this already happens without my patch - it's not a regression.

issue seems to have got worse.

This video shows the behaviour with the delay-hide-SR glitch fix (100ms delay), but with the drift fix disabled when loading scrollback (so you can see the bubbles bounce around as scrollback loads). It largely behaves okay other than the topmost visible bubble bug:

okayish.mp4

However, immediately afterwards, on a hunch, i scrolled back to timeline with an image... and then the send animation broke intermittently:

borked.mp4

Looks like the SR hiding delay might still not be big enough - or perhaps we're actually racing with the unsent->sending->sent transitions. That wouldn't explain why it gets worse when you load scrollback however. It feels more likely that the problem here is entangled with whatever causes the topmost row contents to disappear.

I've run out of time to play with this. Next steps on this are:

• Find out why loading in lots of scrollback in the room then makes things more likely to glitch (is it because we need to de-race hiding the SR with a larger delay)?
• Investigate why the row at the top of the table blinks on and off. Cell reuse, or y-offset confusion due to getting confused about heights?
• Figure out how to disable the top-padding animation properly, so it doesn't break loading images.

[ara4n]

I stabbed at this a bit more:

• Find out why loading in lots of scrollback in the room then makes things more likely to glitch (is it because we need to de-race hiding the SR with a larger delay)?

Yes, it is - increasing the delay to 1s makes the glitches go away; previously i had it at 100ms, so presumably having slowed everything down by loading loads of rows into the UITableView meant it was taking over 100ms to respond, so racing and glitching again. The glitch here is that the SR pops out of visibility rather than animating nicely away.

• Investigate why the row at the top of the table blinks on and off. Cell reuse, or y-offset confusion due to getting confused about heights?

It's worth noting this still happens (most noticeable when a large row like an image goes off the top of the page) when vertical-flipping is disabled.

• Figure out how to disable the top-padding animation properly, so it doesn't break loading images.

With flipping disabled and a long SR-hide-delay the top-padding animation fix seems to work (and doesn't break loading images).

[ara4n]

Okay, after some more testing, conclusions are:

• Removing the unsent->sent transition doesn't change anything
• Removing the vertical-flipping doesn't change anything.
• Adding a .transition(.identity) to the TimelineDeliveryStatusView makes the SR disappear instantly, avoiding any z-index flickering artefacts, but the UITableView row still slowly resizes even if the SR disappears instantly, and so the main "SR pops and cells disappear" glitches still happen presumably due to the animations clashing.
• However, adding a longer delay in removing the SR (200ms) fixes all glitches - especially with the log level dialled down, as the SR removal animation then happens after the UITableView insertion animation.
• This is true even if you load in tonnes of scrollback.
• Reintroducing the .animation(nil, value: messageBubbleTopPadding) on TimelineItemBubbledStylerView doesn't break anything (the "images don't load" problem must have been a data connectivity issue), and does fix scroll jumps & drift when backpaginating. In fact, I haven't seen a scrolljump at all since adding it.

So, the only disadvantage of this is that the previous SR disappears after the new msg gets inserted, causing a two-phase animation, where the whole timeline bumps down a bit after the old SR disappears, which looks like this:

ScreenRecording_05-19-2025.17-50-23_1.MP4

I've pushed this at commit ecc9953

This looks way more deliberate and less glitchy than the original oversteer bug, but i guess the new animation may not be to everyone's tastes.

I'll have an experiment with seeing if we can make the SR disappear instantly in such a way that it doesn't pop or clash with UITableView's animations. Options might be:

• Explicitly disable animation on the TimelineItemBubbledStylerView via .animation(nil, value: context.viewState.timelineState.uniqueIDs.last) or similar so it never reanimates when the timeline changes
• Ensure we remove the SR somehow before the UITableView tries to add the new row, hoping that the race isn't as bad that way around?