This bug prevents me using wayland...

I can confirm the following behaviour from this bug on Fedora 24/GNOME Wayland:

* ~ 30 s spinner in top bar;
* not shown in Alt-Tab list until after that time;
* only happens under GNOME Wayland.

As far as I can tell, this affects (most) applications with .desktop files whose name is [DBus path].desktop

These are mostly DBusActivatable=true .desktop files, but that is not necessary to trigger this bug.

On my system I have the following .desktop launchers in /usr/share/applications with names that correspond to existent DBus paths:

Launchers containing DBusActivatable=true:

ca.desrt.dconf-editor.desktop
org.gnome.baobab.desktop
org.gnome.Books.desktop         *
org.gnome.Boxes.desktop
org.gnome.Builder.desktop
org.gnome.Calendar.desktop
org.gnome.Characters.desktop    *
org.gnome.Cheese.desktop
org.gnome.clocks.desktop
org.gnome.Contacts.desktop
org.gnome.Devhelp.desktop
org.gnome.DiskUtility.desktop
org.gnome.Documents.desktop     *
org.gnome.font-viewer.desktop
org.gnome.gedit.desktop
org.gnome.Logs.desktop
org.gnome.Maps.desktop
org.gnome.Nautilus.desktop
org.gnome.Photos.desktop
org.gnome.Polari.desktop        *
org.gnome.Screenshot.desktop
org.gnome.Software.desktop
org.gnome.Todo.desktop
org.gnome.Totem.desktop
org.gnome.Weather.Application.desktop

Launchers not containing DBusActivatable=true:

org.gnome.bijiben.desktop
org.gnome.SoundRecorder.desktop *
org.gnome.Terminal.desktop

Launchers marked with * are not affected by the bug.

Renaming a launcher to anything other than an existent DBus name (even for example org.gnome.test.desktop) results in the bug not manifesting when launching that application. This can only be done for the non-DBusActivatable launchers, since the others rely on the file name for DBus activation (as per https://wiki.gnome.org/HowDoI/DBusApplicationLaunching#Changes_to_the_desktop_file).

The bug is triggered when launching:

* from the app icon in the overview;
* via a pre-defined keyboard shortcut (e.g. the "Home folder" launcher shortcut).

The bug isn't triggered when launching:

* by opening the desktop launcher under /usr/share/applications via Nautilus; 
* by calling the executable directly (from the Run dialogue, a terminal, a custom keyboard shortcut etc.
* via gapplication launch, e.g. gapplication launch org.gnome.Cheese

I can confirm this issue with Gnome-shell 3.18.x, 3.20.x and 3.21.90.

Can you please add "WaylandRelated" to the "Blocks:" field?

Downstream report:
https://bugzilla.redhat.com/show_bug.cgi?id=1376471

*** Bug 771639 has been marked as a duplicate of this bug. ***

I can confim this on Arch running 3.22 beta 2. Annoying...

*** Bug 772617 has been marked as a duplicate of this bug. ***

*** Bug 772737 has been marked as a duplicate of this bug. ***

*** Bug 773013 has been marked as a duplicate of this bug. ***

Created attachment 338117 [details] [review]
gdkdisplay-wayland: Add API to set startup notification ID

For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.

Created attachment 338118 [details] [review]
wayland: Set startup ID from GApplication platform data

The GApplication platform data may contain a startup ID that on X11
is used to set the startup notification ID when activated. Do the
same on the wayland backend to make startup notifications work for
DBus-activated applications where the DESKTOP_STARTUP_ID environment
variable is not set.

Created attachment 338120 [details] [review]
gtk-shell: Work around non-working startup notifications

GNOME Shell relies on the MetaScreen::startup-sequence-changed signal,
which is tied to (lib)startup-notification and therefore X11. As a result,
when we remove the startup sequence of a wayland client, GNOME Shell will
not be notified about this until startup-notification's timeout is hit.
As a temporary stop-gap, go through XWayland even for wayland clients,
so that the signal is emitted when expected.

It affects too to another GTK applications: Gnome MPV, Audacious (GTK3 version), GRadio,... If it helps we could report failed programs when we detect them.

I think the easiest workaround for those who want to continue using Wayland normally is change the desktop files of conflictive programs manually changing "StartupNotify=false" or with an application like menulibre ( https://smdavis.us/projects/menulibre/ )

(In reply to Simón from comment #13)
> It affects too to another GTK applications: Gnome MPV, Audacious (GTK3
> version), GRadio,... If it helps we could report failed programs when we
> detect them.

No, "some programs are broken" is a huge red herring. Startup notifications are broken for *all* wayland clients, there are just some cases where the regular window matching ends up producing the correct app state.

Review of attachment 338117 [details] [review]:

ok. I think we can bend the rules a little, and accept this in 3.22, since it is backend-specific and not going to be used outside of GTK+

Review of attachment 338118 [details] [review]:

sure

Review of attachment 338117 [details] [review]:

::: gdk/wayland/gdkdisplay-wayland.c
@@ -799,0 +799,16 @@
+/**
+ * gdk_wayland_display_set_startup_notification_id:
+ * @display: (type GdkWaylandDisplay): a #GdkDisplay
... 13 more ...

I think it's important to provide an accurate Since tag:

Since: 3.22.3

Alternatively, couldn't this go through GdkPrivateVTable ? We can't get rid of gdk_x11_display_set_startup_notification_id, but we could make this per-platform inside GDK and abtract it to a single GDK_PRIVATE_CALL in gtk/ without adding API that's just useful to GTK+.

sounds better to me. Who is going to write that patch ? Carlos ? Florian ?

I'll look into it.

Attachment 338117 [details] pushed as 75ee402 - gdkdisplay-wayland: Add API to set startup notification ID
Attachment 338118 [details] pushed as 0bccddb - wayland: Set startup ID from GApplication platform data

Tested previous patches, not fixing issue with nautilus here...

Nautilus is a particular case: background process creating a new window...

(In reply to Matthias Clasen from comment #21)
> Attachment 338117 [details] pushed as 75ee402 - gdkdisplay-wayland: Add API
> to set startup notification ID
> Attachment 338118 [details] pushed as 0bccddb - wayland: Set startup ID from
> GApplication platform data

Uhm, wasn't the consensus now to not go with those patches but implement Carlos' suggestion from comment #18 instead?

(In reply to Cédric Bellegarde from comment #22)
> Tested previous patches, not fixing issue with nautilus here...
> 
> Nautilus is a particular case: background process creating a new window...

Did you include the mutter patch? The GTK+ patches only make DBus-activated clients set the startup notification ID when activated, they don't change the fact that startup notifications are currently broken for all wayland clients.

For what it's worth, I did include nautilus in my testing, and it works as expected with all patches applied ...

You're right, bug fixed, bye bye xorg ;)

May be related to startup notification stuff: https://bugzilla.gnome.org/show_bug.cgi?id=774130

(In reply to Florian Müllner from comment #23)
> (In reply to Matthias Clasen from comment #21)
> > Attachment 338117 [details] pushed as 75ee402 - gdkdisplay-wayland: Add API
> > to set startup notification ID
> > Attachment 338118 [details] pushed as 0bccddb - wayland: Set startup ID from
> > GApplication platform data
> 
> Uhm, wasn't the consensus now to not go with those patches but implement
> Carlos' suggestion from comment #18 instead?

I ended up pushing them as-is. Didn't seem like such a big deal to have some backend api, and I needed a fix right away to meet f25 deadlines.

If we come up with an api-less version for gtk4, thats still appreciated.

Has this patches been reverted? Can't find theme in mutter history.

The patches marked as "committed" in this bug are for GTK+. A better fix is being worked out for mutter.

Any news on this?

Can Fedora workaround be applied to Mutter until a better fix arises?

http://pkgs.fedoraproject.org/cgit/rpms/mutter.git/tree/startup-notification.patch?h=f25

Yay, this bug disappeared on stock Arch today due to mutter upgrade 3.22.2+5+gd9fc81e-1 -> 3.22.2+6+g06f5b6b3e-1 which includes the startup notification patch as seen at https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mutter&id=9b194c696d09ee1a2cf593993d6ad1979c436e65.

Yes, I can confirm that this bug is solved on Arch now. \o/

*** Bug 766917 has been marked as a duplicate of this bug. ***

*** Bug 779829 has been marked as a duplicate of this bug. ***

Created attachment 357651 [details] [review]
core: Make MetaStartupNotificationSequence a public object

It replaces the single public usage of SnStartupSequence we have
in place.

Created attachment 357652 [details] [review]
core: Add meta_startup_notification_sequence_x11_get_wmclass()

This is only necessary in internal paths for X11 clients, so make it
private API.

Created attachment 357653 [details] [review]
core: Make get_sequences() return MetaStartupNotificationSequences

Created attachment 357654 [details] [review]
core: Add meta_startup_notification_sequence_get_workspace()

And fill that in for the X11 case.

Created attachment 357655 [details] [review]
core: Add meta_startup_notification_sequence_get_application_id()

This is necessary on the gnome-shell side, so it can look up a ShellApp
from a startup sequence.

Created attachment 357656 [details] [review]
core: Add meta_startup_notification_sequence_is_complete()

So listeners of startup-sequence-changed can check whether the sequence
is completed.

Created attachment 357657 [details] [review]
core: Mark sequence as complete on SN_MONITOR_EVENT_COMPLETED

So listeners can check the sequence completion.

Created attachment 357658 [details] [review]
shell: Drop API usage of SnStartupSequence

Mutter changed all public API usage of SnStartupSequence with
MetaStartupNotificationSequence. Change the src/shell* code to do the
same, and propagate these such objects forward on ::startup-sequence-changed
signals.

The only API used on javascript around these objects is
shell_startup_sequence_get_app(), which remains in src/shell-window-tracker.c
as helper API. So the Javascript code needed no changes. All the additional
API wrapping a ShellStartupSequence/SnStartupSequence was unused, so they
were deleted in this commit.

Review of attachment 357651 [details] [review]:

::: src/core/screen.c
@@ +234,3 @@
                   0,
                   NULL, NULL, NULL,
+                  G_TYPE_NONE, 1, META_TYPE_STARTUP_NOTIFICATION_SEQUENCE);

This API change could be communicated better in the commit message.

::: src/core/startup-notification.c
@@ +598,3 @@
 {
   MetaStartupNotification *sn = user_data;
+  MetaStartupNotificationSequence *seq = NULL;

(Ugh, confusing naming, how to tell which one is the Sn one elsewhere? (note, just casual whining, please ignore).

@@ +654,3 @@
+    {
+      const gchar *id = sn_startup_sequence_get_id (sequence);
+      g_set_object (&seq,meta_startup_notification_lookup_sequence (sn, id));

space after ",". read this as &seq.meta_... at first :P

::: src/meta/startup-notification.h
@@ +21,3 @@
+
+typedef struct _MetaStartupNotificationSequence MetaStartupNotificationSequence;
+typedef struct _MetaStartupNotificationSequenceClass MetaStartupNotificationSequenceClass;

Shouldn't be needed right? The G_DECLARE_DERIVABLE_TYPE() does this for us IIRC.

Review of attachment 357652 [details] [review]:

::: src/core/startup-notification-private.h
@@ +46,3 @@
 GSList * meta_startup_notification_get_sequences   (MetaStartupNotification *sn);
 
+const gchar *meta_startup_notification_sequence_x11_get_wmclass (MetaStartupNotificationSequence *seq);

nit: Space after "const gchar *" is the style used above.

::: src/core/startup-notification.c
@@ +392,3 @@
+
+  if (!META_IS_STARTUP_NOTIFICATION_SEQUENCE_X11 (seq))
+    return NULL;

Should this be g_return_if_fail (..) instead? Seems to be a programming error if this is used for non-x11 sequences.

Review of attachment 357653 [details] [review]:

::: src/core/screen.c
@@ +2445,1 @@
+          wmclass = meta_startup_notification_sequence_x11_get_wmclass (seq);

Seems like this could be a

meta_window_matches_startup_notification_sequence() that is implemented as below in MetaWindowX11 only
?

::: src/core/startup-notification.c
@@ +766,3 @@
 meta_startup_notification_get_sequences (MetaStartupNotification *sn)
 {
+  return g_slist_copy (sn->startup_sequences);

Could we maybe now skip the copy, and just have whatever uses this sequence non-copy-get it every time? (i.e. remove it from MetaScreen)

Review of attachment 357654 [details] [review]:

::: src/core/startup-notification.c
@@ +253,3 @@
                         G_PARAM_CONSTRUCT_ONLY);
+  seq_props[PROP_SEQ_WORKSPACE] =
+    g_param_spec_int64 ("workspace",

This looks rather like an "ID" of some kind, as I'd otherwise expect a "workspace" property refer to a MetaWorkspace.

::: src/meta/startup-notification.h
@@ +33,3 @@
 const gchar *meta_startup_notification_sequence_get_id        (MetaStartupNotificationSequence *seq);
 gint64       meta_startup_notification_sequence_get_timestamp (MetaStartupNotificationSequence *seq);
+gint64       meta_startup_notification_sequence_get_workspace (MetaStartupNotificationSequence *seq);

Same as the other comment, 'get_workspace()' sounds more like it should return a MetaWorkspace. If that is really to inconvenient, then seems to be better to make it clear this is an ID, so that we could later add a "get_workspace()" that gets return the actual workspace.

Review of attachment 357655 [details] [review]:

lgtm.

Review of attachment 357656 [details] [review]:

::: src/core/startup-notification.c
@@ +89,3 @@
   gint64 timestamp;
   gint64 workspace;
+  guint  completed : 1;

nit: s/completed/is_complete/.
Alternatively 'has_completed' everywhere, as 'is_complete' rather means that it is "complete" as in has all required data or something, not that it has completed its task (I think).

Review of attachment 357657 [details] [review]:

Makes sense to me.

Created attachment 360419 [details] [review]
core: Make MetaStartupNotificationSequence a public object

It aims to replace the public API where we directly use SnStartupSequence.
For starters, the MetaScreen::startup-sequence-changed signal has been
changed to be invoked with a MetaStartupNotificationSequence parameter.

Created attachment 360420 [details] [review]
core: Add meta_startup_notification_sequence_x11_get_wmclass()

This is only necessary in internal paths for X11 clients, so make it
private API.

Created attachment 360421 [details] [review]
core: Add meta_startup_notification_sequence_get_workspace()

And fill that in for the X11 case.

Created attachment 360422 [details] [review]
core: Add meta_startup_notification_sequence_get_application_id()

This is necessary on the gnome-shell side, so it can look up a ShellApp
from a startup sequence.

Created attachment 360423 [details] [review]
core: Make get_sequences() return MetaStartupNotificationSequences

Which also involves updating all the mutter code that uses these startup
sequences to use MetaStartupNotificationSequence API. In order to abstract
things a bit further, MetaWindow has been added a
matches_startup_notification_sequence() vmethod that X11 windows do
implement through wmclass matching.

Created attachment 360424 [details] [review]
core: Add meta_startup_notification_sequence_has_completed()

So listeners of startup-sequence-changed can check whether the sequence
is completed.

Created attachment 360425 [details] [review]
core: Mark sequence as complete on SN_MONITOR_EVENT_COMPLETED

So listeners can check the sequence completion.

Created attachment 360426 [details] [review]
core: Add public MetaStartupNotification getter from MetaDisplay

This replaces (and removes) meta_screen_get_startup_sequences().
The MetaScreen::startup-sequence-changed signal is also useless since
the MetaStartupNotification has a ::changed signal itself, so it has been
removed as well.

Created attachment 360427 [details] [review]
shell: Drop API usage of SnStartupSequence

Mutter changed all public API usage of SnStartupSequence with
MetaStartupNotification and its own sequence objects. Change the src/shell*
code to use the new API and also expose MetaStartupNotificationSequence
objects in the ShellWindowTracker signals/API.

The only additional API used on javascript around these objects is
shell_startup_sequence_get_app(), which remains in src/shell-window-tracker.c
as helper API, all other helpers are unnecessary and were removed.

The Javascript code had to receive minor updates where the API is actually
different (nominally workspace getters returning a MetaWorkspace instead
of its index), but the gist is pretty much API compatible.

Thanks Jonas for the review! I've applied all comments (except the seq naming nits :). I went for removing the MetaScreen API call and signal in an additional patch, and updated the gnome-shell patch so it uses MetaStartupNotification directly.

Hi upstream 

I've just checked mutter in fedora, openSUSE, arch and debian, and all are shipping the "startup workaround patch" for this issue.

I'm doing this ping to ensure that this issue is not "forgotten" as it still sits in bugzilla and not in gitlab.

Startup notification almost never works on Arch Linux running Gnome 3.28.2.
I hate when I double click a big file in nautilus to open it and cursor indicates no activity until the file opens.

(In reply to Bjørn Lie from comment #60)
> Hi upstream 
> 
> I've just checked mutter in fedora, openSUSE, arch and debian, and all are
> shipping the "startup workaround patch" for this issue.
> 
> I'm doing this ping to ensure that this issue is not "forgotten" as it still
> sits in bugzilla and not in gitlab.

There are quite a few bugs in that state. Mutter devs normally run mutter/gnome-shell from git for daily use, so be sure we are aware :)

(In reply to Strangiato from comment #61)
> Startup notification almost never works on Arch Linux running Gnome 3.28.2.
> I hate when I double click a big file in nautilus to open it and cursor
> indicates no activity until the file opens.

The current internal protocol doesn't handle launching from applications, no wonder.

We just need an upstreamed wayland protocol that unifies:
1) User activity times
2) Startup notification, both the launcher and launchee sides
3) Focus stealing prevention

Implement it maybe in weston, definitely in mutter, and add support for it in GtkApplication. Wanna help?

(In reply to Carlos Garnacho from comment #62)
> (In reply to Strangiato from comment #61)
> > Startup notification almost never works on Arch Linux running Gnome 3.28.2.
> > I hate when I double click a big file in nautilus to open it and cursor
> > indicates no activity until the file opens.
> 
> The current internal protocol doesn't handle launching from applications, no
> wonder.
> 
> We just need an upstreamed wayland protocol that unifies:
> 1) User activity times
> 2) Startup notification, both the launcher and launchee sides
> 3) Focus stealing prevention
> 
> Implement it maybe in weston, definitely in mutter, and add support for it
> in GtkApplication. Wanna help?

The issue mentioned in comment 61 persists on Gnome 3.34.1, but unfortunately I can't help.
I'm not a software developer. :(

I FTR been idly working since comment #62 towards a protocol that does precisely that. I still need to make POC implementations, hopefully this 3.36 material but more realistically 3.38 since it should be discussed and agreed in the wayland ML first.

Carlos: Did that materialize for 3.38, by any chance? :)

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.