After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 771557 - Polari user list Popover/ScrolledWindow - brief visual glitches during 1st popup() event per room
Polari user list Popover/ScrolledWindow - brief visual glitches during 1st po...
Status: RESOLVED FIXED
Product: polari
Classification: Applications
Component: general
3.21.x
Other Linux
: Normal normal
: ---
Assigned To: Polari maintainers
Polari maintainers
: 772711 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-09-16 22:06 UTC by Daniel Boles
Modified: 2016-10-10 22:02 UTC
See Also:
GNOME target: ---
GNOME version: 3.21/3.22


Attachments
screencast (191.72 KB, video/webm)
2016-09-16 22:06 UTC, Daniel Boles
  Details
userList: Postpone propagating height until content limit is set (2.01 KB, patch)
2016-10-10 20:47 UTC, Florian Müllner
committed Details | Review

Description Daniel Boles 2016-09-16 22:06:02 UTC
Created attachment 335737 [details]
screencast

This is a little visual glitch but hopefully is useful to report. Having looked at the JS (Polari 3.21.92), I don't know enough to be sure whether this is specific to Polari or general to GTK+ (3.21.6), so please move as appropriate.

For me, this is reproducible in Polari with 2 simple steps:
 * Enter your 1st room, or change to another one - so that the user list is refreshed.
 * Click on the user count Button to bring up its Popover/ScrolledWindow of users.
 * Expected result: The Popover/ScrolledWindow will neatly pop up at the right size and in the right place relative to the Button.
 * Actual result: It pops up, visibly too large and in the wrong position - then quickly fixes itself.

It seems that, for a brief moment, when the user list is shown, it initially gets allocated too much size and gets cut off at the top, just above the parent GtkWindow. It also gets positioned to the left of the relative-to Button, rather than below as normal.

This same symptoms happened in previous 3.21.x versions - but were permanent - until Polari and GTK+ in turn patched things to make this (A) worked around then (B) not necessary as propagation of child natural sizes became opt-in.

However, I've noticed that in both incarnations of the fix - although the Popover eventually settles at the correct size - it has shown the aforementioned glitch during the initial process of becoming visible. So I thought it might be worth reporting in case there's a gremlin in the works...

I'm attaching a screencast of this using the steps mentioned above. Hope this helps, and let me know if you'd like any other info.
Comment 1 Florian Müllner 2016-10-10 20:25:43 UTC
*** Bug 772711 has been marked as a duplicate of this bug. ***
Comment 2 Florian Müllner 2016-10-10 20:47:28 UTC
Created attachment 337353 [details] [review]
userList: Postpone propagating height until content limit is set

For the user list popover to work as intended, we have to set both
:max-content-height - to limit the number of displayed entries - and
:propagate-natural-height - to actually request more than the minimum
height. As computing the former requires the rows' allocations, we
can only set it after the initial size request, however we currently
set the latter immediately. As a result, there's a short span where
the popover is set to request the full content height, which at best
leads to a visual glitch when the popover briefly flashes at full
height, and in the worst case will crash when the windowing system's
limits are exceeded. Fix this by only propagating the height once
the maximum content height is set as well.
Comment 3 Bastian Ilsø 2016-10-10 21:24:17 UTC
Review of attachment 337353 [details] [review]:

looks good to me.
Comment 4 Florian Müllner 2016-10-10 21:27:34 UTC
Attachment 337353 [details] pushed as 240afe9 - userList: Postpone propagating height until content limit is set
Comment 5 Daniel Boles 2016-10-10 22:02:27 UTC
Thanks all! Especially good catch from Jiri noticing it outright crashed on sufficiently large lists - shows that I don't visit busy enough rooms. :D