Suggest section header rendered in wrong place

[HarHarLinks]

Steps to reproduce

Not sure, I just noticed it had happened. Probably when a room bubbled to the top by activity?

Outcome

What did you expect?

/

What happened instead?

Operating system

arch

Application version

nightly

How did you install the app?

aur

Homeserver

No response

Will you send logs?

No

[novocaine]

Was this a one-off, or something you can consistently reproduce?

[HarHarLinks]

Seems to happen every time I switch to the #community:matrix.org space, nightly 21-10-19 today

[HarHarLinks]

Element Nightly version: 2021102101, still happening 100% of the time when I switch to the space. Would it be useful to submit any logs or similar?

I haven't mentioned before that if I scroll the room list enough to hit the point where the suggested collapse thing stops floating, it'll fix itself. Until I switch spaces back and forth again. It never happens with the same Low Priority section collapsy thingy in my other space (it doesn't have a suggested). I can reproduce also with different window sizes. It happens regardless of running with ozone or without.

[t3chguy]

Related #17283

[turt2live]

We've fixed a case of this already and it looks very similar to what this issue describes. If you're still seeing this, please open a new issue with fresh information for reconsideration.

[HarHarLinks]

I'm sorry, but I don't understand why you are closing this issue.
This is an ongoing problem and unresolved since (before) I first opened it, here is some evidence of it in Element Nightly version: 2022050701

It happens 100% consistently for me.

I don't know what more information you expect me to be able to provide? But just closing unresolved issues doesn't seem an appropriate way to handle things.

It feels like it has to do with how that particular floaty string is implemented. I think you need the room list to be just so long that the low priority section is still visible while the suggested rooms section is not supposed to be visible. I think it also has to do with how element/electron gets the window size (height in particular) and when scripts are applied that handle it. I would bet this is a race condition somewhere between getting the info about suggested rooms, which seems to work slightly different from the rest of the room list based on the observation that it often reacts delayed in comparison, the floaty code for that string, and getting the window size.
Alternatively I can imagine the wm reporting a wrong-ish window size to electron, e.g. calculating it including or excluding the window frame. To that end: I'm using sway with title in the window frame enabled at the top as well as waybar above it, while element is running through xwayland (since native support is broken element-hq/element-desktop#728).

[robintown]

Reopening this then, with a note that this has likely the same underlying cause as #21848

[HarHarLinks]

Still in Element version: 5644c4e-react-0647aafc3a84-js-615f7f9e72fb
Olm version: 3.2.14

[MTRNord]

Happening for me too from time to time. I think I have seen it more often one reloads or when archiving rooms.

[HarHarLinks]

I have no idea how this can't be reprod (per the label)? I see it almost any time I look at a space with sufficiently many rooms to cause y-overflow.

[HarHarLinks]

member_room_name.mp4

[HarHarLinks]

here's the same bug but with the server notices section header instead