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.

There is a failing snapshot test that needs eyes on it. If it makes sense, update it with UPDATE_SNAPSHOTS=1 cargo test --all-features

Hm... I'll check it out tomorrow

Hey! Yeah, the demo::demo_app_windows::tests::demos_should_match_snapshot test is failing because of a width difference. It's actually related to the TextEdit::singleline bug that this PR fixes, which was messing with the window size.

I'll try to update the snapshots, I hope I'll do it right

I’ve replaced the "Code Example" snapshot with the version from the CI artifact to fix the test failures. However, I need the CI workflow to run so I can verify that everything is correct.
Due to rendering differences between CI and my local machine, I can’t be completely sure that the all snapshots will match perfectly. Running the tests in CI will help confirm that everything is working as expected.

Could you (@emilk or maybe @lucasmerlin?) approve and trigger the workflow when you have time?

Seems like cargo-machete is now failing but that's not your fault 😅 I'll fix that next week

Machete should be fixed by #5745

Thanks again!