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 747509 - GtkPopover is constrained to parent window size on non-Wayland backends
GtkPopover is constrained to parent window size on non-Wayland backends
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkPopover
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 771118 786963 787838 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-04-08 14:48 UTC by Drew
Modified: 2018-05-02 16:30 UTC
See Also:
GNOME target: ---
GNOME version: 3.13/3.14


Attachments
Attached is the open GtkPopover with a smaller in height parent GtkWindow. (8.46 KB, image/png)
2015-04-08 14:48 UTC, Drew
Details

Description Drew 2015-04-08 14:48:53 UTC
Created attachment 301142 [details]
Attached is the open GtkPopover with a smaller in height parent GtkWindow.

My menu inside of a GtkPopover is a good size long.  Longer than the parent GtkWindow.  It gets cut off and won't show the whole popover regardless of parent window size unless I stretch window to cover the whole popover.  Am I missing something to fix this?  Or is this an actual bug with gtk+-3.0?
Comment 1 Matthias Clasen 2015-04-08 14:59:21 UTC
Its a limitation of the GtkPopover implementation under X11. On Wayland, popover happily hang out of the window.
Comment 2 Drew 2015-04-08 16:54:55 UTC
Thanks for the quick reply Matthias!!!  I'm on an Arch machine so 3.16 and Wayland are not quite ready to see this working properly.  Is Gnome Wayland stable enough for day to day in your opinion?
Comment 3 Daniel Boles 2017-08-14 23:57:39 UTC
Is this actually a bug in GTK+ (limited implementation), or does X11 simply make it impossible to have a Popover that hangs out of its parent Window?
Comment 4 Daniel Boles 2017-09-13 21:41:55 UTC
also curious about this: the "X11" path in this code is really 'if not Wayland', but are win32 and macOS actually subject to the same limitation?
Comment 5 Daniel Boles 2017-09-18 17:56:09 UTC
*** Bug 787838 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Boles 2017-10-06 13:07:59 UTC
(In reply to Daniel Boles from comment #4)
> also curious about this: the "X11" path in this code is really 'if not
> Wayland', but are win32 and macOS actually subject to the same limitation?

win32 is. I'm guessing macOS is too.

Which compositors actually need to be limited in this way? and is there a theoretical possibility to give the Popover a full window of its own to fix it? It might get a lot more visible with the advent of things like the EmojiChooser, as seen in Bug 786963
Comment 7 Daniel Boles 2017-10-06 13:08:29 UTC
*** Bug 786963 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Clasen 2017-10-11 16:09:44 UTC
> Which compositors actually need to be limited in this way? and is there a
>  theoretical possibility to give the Popover a full window of its own to fix
> it? It might get a lot more visible with the advent of things like the
> EmojiChooser, as seen in Bug 786963

Yes, it is theoretically possible to reimplement popovers in a different way
Comment 9 Timm Bäder 2018-02-06 11:21:23 UTC
*** Bug 771118 has been marked as a duplicate of this bug. ***
Comment 10 GNOME Infrastructure Team 2018-05-02 16:30:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/543.