This needs protocol. For 3.20 we can only do this using a GNOME only solution (i.e. adding it to gtk_shell or something like that). Is it urgent enough for that?

In the context of LibreOffice it would definitely be nice to get it working. Everything else seems to basically work, or is a problem on my side.

Jonas and I discussed this and the plan is to add this to gtk_shell for 3.20

FWIW, to properly implement this there some serious surgery is needed in mutter. 

In summary, we currently end up with a mix of g_get_monotonic_time() and Xserver timestamps.

Gtk will fetch the last timestamp from the last seen event, pass GDK_CURRENT_TIME, or extract the timestamp from the startup notification ID (or get the time passed by the application which should be the timestamp from the GdkEvent). The event timestamps come from libinput; libinput currently uses G_CLOCK_MONOTONIC. The startup notification ID timestamp though, comes from the X server.

On the mutter side, all the code that deals with raising/activating etc currently assumes the timestamp is from the X server. We have ways to calculate the approximate X server timestamp from a timestamp from the monotonic clock.

To fix things, we need to change mutter to stop relying on timestamps being from the X server. We have two options of doing this; one is to have timestamps to either use the Xserver's clock or the monotonic clock and deal with the difference everywhere (for example make sure to compare to timestamps from the same clock). The other, probably more sane, option is to make sure mutter always uses the monotonic clock internally, and translate all X server timestamps to monotonic clock time.

Some care need to be show for the startup notification specification as well. The current spec is pretty X11:y, and requires the timestamp to be from the X server. We probably can't change the timestamp clock for X11 clients, but we will need to specify the clock the timestamps should be for Wayland clients (probably specified to be "the same clock as input events"). That mean that the startup launcher code (currently in gnome-shell) needs to make sure to generate an ID with a timestamp from the correct clock given the mode mutter runs in.

When those things are fixed, GDK can pass timestamps from the same clock.

I think the mutter surgery is too risky for 3.20.

One thing we could do for 3.20, however, is to ignore all gtk_window_activate* requests that use a timestamp that is not the one from the most recent event, and have mutter fetch the time from the X server, making the rest of the mutter code believe it the activation request just came with an X server timestamp. This would just be a temporary hack around the real issue, so I'm not sure its worth the effort if we are not aiming for 3.20 to be a potential "Wayland by default" release.

I think making window raising work at all is worth it for 3.20, even if we can't make focus stealing prevention work

Created attachment 323360 [details] [review]
wayland: Add request focus support via gtk_shell

A gtk_surface.present request was added to gtk_surface which takes
timestamp from some input event, and uses that timestamp to figure out
whether the window can be presented or not. If we don't have a
timestamp, we should just give up instead of making up our own,
otherwise we might steal someones focus.

The patch ended up pretty simple. Part of the reason is that I currently don't care about the timestamp differences as at least in this case the race condition described in 756272 is hard to hit. The mutter patches can be found in bug 763295.

Review of attachment 323360 [details] [review]:

Is focusing really the same as presenting ?

Looks like it is, in gtk...

Review of attachment 323360 [details] [review]:

.

Attachment 323360 [details] pushed as 8fb7f50 - wayland: Add request focus support via gtk_shell