GNOME Bugzilla – Bug 771557
Polari user list Popover/ScrolledWindow - brief visual glitches during 1st popup() event per room
Last modified: 2016-10-10 22:02:27 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.
*** Bug 772711 has been marked as a duplicate of this bug. ***
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.
Review of attachment 337353 [details] [review]: looks good to me.
Attachment 337353 [details] pushed as 240afe9 - userList: Postpone propagating height until content limit is set
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