GNOME Bugzilla – Bug 734129
Popover sometimes fails to get raised above contents
Last modified: 2014-08-11 00:40:49 UTC
If the popover is given an initial position which is left unchanged, some content in the same area gets mapped afterwards (and its windows raised), and the popover is later shown, the GdkWindows that were shown/raised in such content would be left above the popover one. This is visible in gnome-maps master, where the popover points to an entry inside a revealer. The popover first get a correct initial position (eg. where the revealed entry would lie), but the entry and other revealer contents would be actually mapped when the revealer is shown, making all windows there raised above the popover. _gtk_window_set_popover_position() is called in various places where the position or visibility of a popover might have changed, but is usually a no-op if the position didn't change at all. I'm attaching a patch to have it only avoid gtk_widget_queue_resize() in those situations, still realizing/showing/raising the GdkWindow if necessary.
Created attachment 282282 [details] [review] window: Only avoid queueing resizes if the popover position didn't change If the same position is requested on a popover, it should at least ensure the window is realized and raised, even if no resizes are queued on the content. Otherwise other widgets being mapped might raise the windows over the popover's if its original position is unchanged.
Attachment 282282 [details] pushed as 25721ae - window: Only avoid queueing resizes if the popover position didn't change
*** Bug 732054 has been marked as a duplicate of this bug. ***