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 770745 - wayland: Warn when an application tries to map popup incorrectly
wayland: Warn when an application tries to map popup incorrectly
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-09-02 10:56 UTC by Jonas Ådahl
Modified: 2018-01-25 15:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: Warn when an application tries to map popup incorrectly (2.58 KB, patch)
2016-09-02 10:56 UTC, Jonas Ådahl
committed Details | Review

Description Jonas Ådahl 2016-09-02 10:56:01 UTC
Warning instead of actually mapping a non-top most popup makes misbehaving
applications emit warnings instead of being terminated by the compositor.

For example this makes Eclipse not abort when right-clicking on the
"Perspective" switcher icons when they are in a horizontal tool bar.
Comment 1 Jonas Ådahl 2016-09-02 10:56:05 UTC
Created attachment 334633 [details] [review]
wayland: Warn when an application tries to map popup incorrectly

When a popup is mapped but will not be the top most popup (for example
the parent is not the current top most popup, or if there already is a
popup mapped but the parent is a toplevel), warn and ignore it instead
of continuing, as continuing would be a protocol violation.
Comment 2 Matthias Clasen 2016-09-02 13:07:14 UTC
Review of attachment 334633 [details] [review]:

sure, if this is a protocol violation, we shouldn't do it
Comment 3 Jonas Ådahl 2016-09-02 13:10:14 UTC
(In reply to Matthias Clasen from comment #2)
> Review of attachment 334633 [details] [review] [review]:
> 
> sure, if this is a protocol violation, we shouldn't do it

I'm contemplating whether xdg-shell is too strict here as well. Since the compositor can dismiss at any time, the client wont reliably know when whether a parent is actually top most or not. Either way, GTK+ shouldn't do it anyway.
Comment 4 Jonas Ådahl 2016-09-02 13:13:57 UTC
Attachment 334633 [details] pushed as 98b0f78 - wayland: Warn when an application tries to map popup incorrectly
Comment 5 Marinus Schraal 2016-09-04 13:44:42 UTC
*** Bug 770752 has been marked as a duplicate of this bug. ***
Comment 6 Eric Williams 2018-01-23 16:34:48 UTC
What protocol does this violate? And why only on Wayland and not X11? 

I am dealing with a bug in SWT that is related to this fix -- if you could explain the logic here it would help understand the issue further.
Comment 7 Jonas Ådahl 2018-01-24 04:14:14 UTC
(In reply to Eric Williams from comment #6)
> What protocol does this violate? And why only on Wayland and not X11? 

The xdg-shell protocol. It doesn't violate anything on X11 because X11 is more of a "you're on your own" windowing system, while Wayland is much less so.

> 
> I am dealing with a bug in SWT that is related to this fix -- if you could
> explain the logic here it would help understand the issue further.

The warning should happen when you map a popup (i.e. a popup menu that grabs input) above some other window that is not the top most popup or the toplevel.

For example, lets say you have a toplevel window (e.g. the "main" window of your application) and an already open popup menu with the toplevel as a parent. Then you open another popup menu before closing the first one, but the new popup menu also has the toplevel window as the parent. In xdg-shell (the Wayland protocol that provides methods for creating "windows", "menus" etc), this is now allowed, since that would mean two menus would "grab" the same input device at the same time, which makes no sense.

If you need to have multi level menus, what you need to do is to make sure that each new child menu is mapped with the old top most child menu as parent. If you are not using GtkMenu, you might be interested in bug 791845.
Comment 8 Jonas Ådahl 2018-01-24 07:56:11 UTC
(In reply to Jonas Ådahl from comment #7)

... snip ..
> For example, lets say you have a toplevel window (e.g. the "main" window of
> your application) and an already open popup menu with the toplevel as a
> parent. Then you open another popup menu before closing the first one, but
> the new popup menu also has the toplevel window as the parent. In xdg-shell
> (the Wayland protocol that provides methods for creating "windows", "menus"
> etc), this is now allowed, since that would mean two menus would "grab" the
> same input device at the same time, which makes no sense.

That should be ".., this is *not* allowed, ...". Sorry for the typo
Comment 9 Eric Williams 2018-01-25 15:35:57 UTC
(In reply to Jonas Ådahl from comment #7)
> (In reply to Eric Williams from comment #6)
> > What protocol does this violate? And why only on Wayland and not X11? 
> 
> The xdg-shell protocol. It doesn't violate anything on X11 because X11 is
> more of a "you're on your own" windowing system, while Wayland is much less
> so.
> 
> > 
> > I am dealing with a bug in SWT that is related to this fix -- if you could
> > explain the logic here it would help understand the issue further.
> 
> The warning should happen when you map a popup (i.e. a popup menu that grabs
> input) above some other window that is not the top most popup or the
> toplevel.
> 
> For example, lets say you have a toplevel window (e.g. the "main" window of
> your application) and an already open popup menu with the toplevel as a
> parent. Then you open another popup menu before closing the first one, but
> the new popup menu also has the toplevel window as the parent. In xdg-shell
> (the Wayland protocol that provides methods for creating "windows", "menus"
> etc), this is now allowed, since that would mean two menus would "grab" the
> same input device at the same time, which makes no sense.
> 
> If you need to have multi level menus, what you need to do is to make sure
> that each new child menu is mapped with the old top most child menu as
> parent. If you are not using GtkMenu, you might be interested in bug 791845.

Okay thanks, this was very helpful. We could definitely make use of that public API so I'll comment in that bug.