Hi Martin, can you provide a simple reproducer?

gtk3-demo seems to work fine and a simple menu app I had works fine as well on current f23 with gnome-3.17.9x.

There used to be some issues with popup menu some times ago but it's been fixed in both mutter and gtk+

https://bugzilla.gnome.org/show_bug.cgi?id=749716
https://bugzilla.gnome.org/show_bug.cgi?id=748951
https://bugzilla.gnome.org/show_bug.cgi?id=749717

Okay, taking back for now - looks like Firefox emits too much input events so the window is created and then destroyed by Firefox itself.

It's cause bu focus-out event which is send to container window (e.g. event widget) right after the popup is created. But the popups should not have the focus, it must stay on parent window as on X11.

Olivier, I found the problem. When I create a popup (and set it transient for the parent) the new popup receives focus-in and parent gets focus-out. I don't see this on X11 where focus is still on parent. Is that related to the position problem? Does wayland handle focus differently?

Created attachment 1084643 [details]
Test program

(In reply to Martin Stransky from comment #4)
> Olivier, I found the problem. When I create a popup (and set it transient
> for the parent) the new popup receives focus-in and parent gets focus-out. I
> don't see this on X11 where focus is still on parent. Is that related to the
> position problem? Does wayland handle focus differently?

I don't see this being mentioned in the docs for Wayland [1] and I cannot reproduce using the attached reproducer, focus remains on the main window even when the popup is mapped on screen.

I suspect gdk is not using a popup in your case, especially if the (expected to be popup) window is not placed relative to its parent window.

[1] http://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Input

Created attachment 1084644 [details]
Test program

(fix the confusing messages in the focus in/out handlers)

(In reply to Olivier Fourdan from comment #5)
> I suspect gdk is not using a popup in your case, especially if the (expected
> to be popup) window is not placed relative to its parent window.
> 
> [1] http://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Input

Yes, that may be the case - but the window is created as GTK_WINDOW_POPUP so one may expect it is a popup ;-) So the example you created for correct placing should also fix the focus, right?

(In reply to Martin Stransky from comment #7)
> Yes, that may be the case - but the window is created as GTK_WINDOW_POPUP so
> one may expect it is a popup ;-) So the example you created for correct
> placing should also fix the focus, right?

Specifying a GTK_WINDOW_POPUP does not imply that gdk will use an XdgPopup eventually, see what I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1264355#c10 

You need a grab as well otherwise the gdk backend for Wayland will not create an xdg_popup, as this is required anyway by the xdg_popup:

http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n542

(In reply to Martin Stransky from comment #7)
> So the example you created for correct placing should also fix the focus,
> right?

I don't see any focus transition with xdg_popup.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Olivier, I just came across this bug again and looks like the recent mutter version has this bug now. I tested your example (Thanks for it!) and it shows that focus *is* transferred on wayland/mutter while it stays on weston. Will file bug at b.g.o for that. Thanks!

Filed as https://bugzilla.gnome.org/show_bug.cgi?id=783957