When input method panel becomes shorter, the shortened region is still visible

[lilydjwg]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Enable plugin input-method-v1
2. Find a text field and start typing using input method
3. When input method panel becomes shorter (but not moved), the shortened region is still visible

Expected behavior
The shortened region should disappear and whatever was below is now showing.

Screenshots or stacktrace

https://github.com/user-attachments/assets/19d8f7c3-4dc6-4101-ac85-7d7cd60b718d
(It's better to download the screencast and view frame by frame.)

Wayfire version
git

[ammen99]

Is this a regression? I think it was working well previously. I vaguely remember something about wlroots changing something about damage accumulation ...

[lilydjwg]

Yes, it's a regression.

[soreau]

As ammen99 realized on chat, there was a breaking change we did not account for in the wlroots 0.18 port: "wlr_surface_get_effective_damage() no longer takes into account resizes and sub-surfaces." So, does this patch help?

[lilydjwg]

That patch fixes it for the most of time (e.g. the issue demonstrated in above video), but it still occurs occasionally and in specific situation.

It still happens in Telegram.

This seems to only happen when xfce4-appfinder is displayed above the wallpaper:

out.mp4

Firefox & GNOME Terminal is constantly repainting (using the showrepaint plugin) so it doesn't happen, but constantly repainting is an issue.

[soreau]

Actually, that patch is not the right fix at all. Apparently it requires additional work, but so far, I haven't found a proper solution. But, thanks for testing, and if I find something else that might work, I'll post it here.

[lilydjwg]

Firefox & GNOME Terminal is constantly repainting (using the showrepaint plugin) so it doesn't happen, but constantly repainting is an issue.

Reverting the patch, GNOME Terminal is back to repaint when necessary, but Firefox is still repainting constantly. Maybe it's a change in Firefox's side. Despite this, without this patch the total power usage drops from 100W to 85W (the application window being displayed doesn't change it).

[soreau]

This patch fixes the issue here, and it seems like a fix closer to the problem.

[lilydjwg]

It almost fixes the issue! Except when the cursor is near the right screen border and the input window was pushed to the left but then shrinks (so it now isn't pushed to the left).

out.mp4

BTW it seems that Firefox did something that has changed its repainting behavior, but nothing bad is happening.

[soreau]

It almost fixes the issue! Except when the cursor is near the right screen border and the input window was pushed to the left but then shrinks (so it now isn't pushed to the left).

Hm, might this be an unrelated problem? Here, when the text cursor is near the right edge, the popup's right edge is aligned with the right edge of the output, and pushed left as expected. So I cannot reproduce this issue currently. The patch fixes damage specifically, and it shouldn't change anything with offset/positioning, as far as I know.

[lilydjwg]

The positioning is correct, but part of an old frame is still visible after it repositions (all containing text to the left side of "1." shouldn't be there; I forgot to use mouse to "remove" those artifacts in the video).

[soreau]

Does this variant happen to help?

[soreau]

Hm, I probably shouldn't overwrite the global geometry .. this patch should do better.

[lilydjwg]

Yes! Last patch has no issue so far!