Preview available at https://egui-pr-preview.github.io/pr/5640-master
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

There are some clippy failures that need fixing

Done. There's still a warning left at crates/egui/src/context.rs:2469:13, but it's outside the scope of this PR, so I didn't touch it.

@juancampa you may wanna have a look at this too

The only thing I'm seeing that could be a regression is the frame delay that appears in the video (bottom border disappears for one frame) but I'll test locally to double check

Ok so the border disappearing is because of the TextArea is animating the scroll, which is expected. However, I can still repro the original issue when scroll animation is disabled (using .animated(false))

Since .horizontal comes with its own scrolling behavior a better fix is to wrap the original code in if !clip_text. It seems to fix all the issues:

This is what I used:

            if !clip_text {
                // Allocate additional space if edits were made this frame that changed the size. This is important so that,
                // if there's a ScrollArea, it can properly scroll to the cursor.
                let extra_size = galley.size() - rect.size();
                if extra_size.x > 0.0 || extra_size.y > 0.0 {
                    ui.allocate_rect(
                        Rect::from_min_size(outer_rect.max, extra_size),
                        Sense::hover(),
                    );
                }
            }

So, the root cause of the original issue is .animated(false), that makes sense now. Yeah, using if !clip_text would definitely work as a workaround for the bug we're talking about.
Ngl, after looking at egui's code, I'm still not sure how animated actually affects the ScrollArea and existing pipeline, so I can't really tell if this behavior is a bug in ScrollArea or TextEdit itself.

Anyway, we need to decide what to do here. If you're both sure that the root cause of the original issue is a flaw in TextEdit, then I can use @juancampa's code in the next commit, if he doesn't object.

The original issue was a bug in TextArea because it was painting outside of its allocated space (for one frame), so there was no way for ScrollArea to scroll to it.

When scroll animation is enabled, it works fine, because ScrollArea continues to scroll to the target for a few frames, and at that point TextArea is allocating the correct amount of space.

Okay, that makes sense. I tried to figure out where the calculation goes wrong, but egui is just too complex and complicated for me. My only suspicion is galley.size() in show_content, but I couldn't understand how galley and layouter are obtained, so I'll leave this to the smarter contributors of this wonderful project :<

The solution from @juancampa does work, but to me, it feels more like a workaround. I'll revert to their code and add an if statement for !clip_text. At the very least, it's the quickest way to fix the bug.