To rule out bug 775869, please use something like

 $ dbus-monitor interface=org.gnome.SessionManager.EndSessionDialog

to see whether the gnome-session side requests a second dialog.

method call time=1493198791.738556 sender=:1.16 -> destination=:1.21 serial=1050 path=/org/gnome/SessionManager/EndSessionDialog; interface=org.gnome.SessionManager.EndSessionDialog; member=Open
   uint32 1
   uint32 0
   uint32 60
   array [
      object path "/org/gnome/SessionManager/Inhibitor64"
      object path "/org/gnome/SessionManager/Inhibitor66"
   ]
signal time=1493198793.610681 sender=:1.21 -> destination=(null destination) serial=1843 path=/org/gnome/SessionManager/EndSessionDialog; interface=org.gnome.SessionManager.EndSessionDialog; member=Canceled
signal time=1493198793.613253 sender=:1.21 -> destination=(null destination) serial=1844 path=/org/gnome/SessionManager/EndSessionDialog; interface=org.gnome.SessionManager.EndSessionDialog; member=Closed

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

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

Previously this only affected the Shutdown and Restart buttons for me, however for some reason starting today the Cancel button is now also affected.

Someone else also reported this issue downstream here: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1683867 So a lot of people seem to have the issue.

I can confirm this bug on Arch running Gnome 3.24.2.

I did some tests, it seems the bug appeared with :

commit 2c070d38fb417dced66bf8589c4caa66bbd2d9ed
system: Switch between alternatives on long-press

I don't know whether it is related, but this bug present on my machine with nouveau video driver and not present on machine with intel driver. And, just for clarity, first click may be executed in any point of screen, after that buttons become active.

I have Intel drivers on this machine and the bug is present as well so I don't think it's driver vendor specific. Though I can confirm that the first click can be done anywhere on the screen, just not 'Cancel' button, because for some reason a single click works on that button at least for me!

I can confirm this bug with the radeon driver.

Fact #1: this bug reproducible under both X and wayland sessions.
Fact #2: buttons become active after 10 seconds without additional click. Can someone else confirm this behavior?

Archlinux
gnome-shell 3.24.2-1
libinput 1.7.2-1
mesa 17.1.1-1

FWIW, I've tried to reproduce this issue in a VM and wasn't able to - after rebooting five times in a row, I stopped trying ...

(In reply to Florian Müllner from comment #13)
> FWIW, I've tried to reproduce this issue in a VM and wasn't able to - after
> rebooting five times in a row, I stopped trying ...

I can reproduce this with a live usb of ubuntu gnome 17.04 and fedora 26 alpha on NVIDIA and Intel. Also on a jhbuild gnome session on real hardware.

The problem seems to be triggered by the Clutter.ClickAction in the AltSwitcher. As soon as I remove it, I don't have to click twice (of course, the long press doesn't work anymore).

(In reply to Florian Müllner from comment #13)
> FWIW, I've tried to reproduce this issue in a VM and wasn't able to - after
> rebooting five times in a row, I stopped trying ...

Maybe special patch for debug output would be helpful?

(In reply to Vladimir Stoyakin from comment #12)
> Fact #2: buttons become active after 10 seconds without additional click.
> Can someone else confirm this behavior?

Buttons do NOT become active after any amount of time on my system with Fedora 26, gnome-shell 3.24.2-1.

Those buttons don't become active after time for me either on both my Intel desktop PC and my Dell XPS 13 (9343) where this problem happens 100% repeatably since GNOME 3.24. Running up to date Arch Linux (gnome-shell 3.24.2-1). The problem still occurs after disabling all extensions and cleanly rebooting.

This bug is re-programming me to double click those buttons for the rest of my life regardless of if/when it gets fixed :(

(In reply to slatchurie from comment #14)
> The problem seems to be triggered by the Clutter.ClickAction in the
> AltSwitcher.

That's a data point, but not enough, otherwise the issue would reproduce for me as well - I've still been unsuccessful (VM and real hardware, touchpad and mouse, X11 and wayland) ...

In any case, given that this sounds like a grab issue in relation to the click action, I'll take a guess - does this patch make a difference:

diff --git a/js/ui/status/system.js b/js/ui/status/system.js
index 02b683075..500ff85c5 100644
--- a/js/ui/status/system.js
+++ b/js/ui/status/system.js
@@ -55,7 +55,10 @@ const AltSwitcher = new Lang.Class({

         this.actor = new St.Bin();
         this.actor.connect('destroy', Lang.bind(this, this._onDestroy));
-        this.actor.connect('notify::mapped', () => { this._flipped = false; });
+        this.actor.connect('notify::mapped', () => {
+            this._flipped = false;
+            this._clickAction.release();
+        });
     },

     _sync: function() {

(In reply to Florian Müllner from comment #18)
> (In reply to slatchurie from comment #14)
> > The problem seems to be triggered by the Clutter.ClickAction in the
> > AltSwitcher.
> 
> That's a data point, but not enough, otherwise the issue would reproduce for
> me as well - I've still been unsuccessful (VM and real hardware, touchpad
> and mouse, X11 and wayland) ...

That's strange because it happens everywhere for me. I haven't tested in a VM though.
Unfortunately, I don't know how to debug gnome-shell/clutter yet.

> In any case, given that this sounds like a grab issue in relation to the
> click action, I'll take a guess - does this patch make a difference:
> 
> diff --git a/js/ui/status/system.js b/js/ui/status/system.js
> index 02b683075..500ff85c5 100644
> --- a/js/ui/status/system.js
> +++ b/js/ui/status/system.js
> @@ -55,7 +55,10 @@ const AltSwitcher = new Lang.Class({
> 
>          this.actor = new St.Bin();
>          this.actor.connect('destroy', Lang.bind(this, this._onDestroy));
> -        this.actor.connect('notify::mapped', () => { this._flipped = false;
> });
> +        this.actor.connect('notify::mapped', () => {
> +            this._flipped = false;
> +            this._clickAction.release();
> +        });
>      },
> 
>      _sync: function() {

And that's a good guess.
I have tested it in a jhbuild session and  trithis does theck for me.
Thanks.

(In reply to Florian Müllner from comment #18)
> In any case, given that this sounds like a grab issue in relation to the
> click action, I'll take a guess - does this patch make a difference:

Confirmed. Patch works for me too.
Thanks.

Applied the patch to both my desktop PC and my notebook and it fixes the problem.

Created attachment 353969 [details] [review]
system: Emulate click action button release

Since commit 2c070d38, we add a ClickAction to the visible AltSwitcher
button to track long-presses. As a result, we now have two components
that will grab and ungrab the pointer for the button, so to make sure
we don't end up with a stuck grab, we need to release the second's
component grab when the first activates.

Currently we only drop the StButton grab on long-press, we also need
to cancel any initiated long-press on click.

The attached patch *should* do the same as the one pasted earlier, but I did change it a bit to make more sense, so retesting would be highly appreciated.

(Given that I cannot test it myself - I still don't understand under what exact conditions the issue occurs, which makes me slightly uncomfortable ...)

That second patch also fixes the problem on my desktop PC and my notebook.

I can confirm. With the latest patch, both the shutdown dialog and the long press action work as intended.

Awesome, thanks! I'll wait for code review then ...

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

Review of attachment 353969 [details] [review]:

makes sense

Attachment 353969 [details] pushed as 2339c39 - system: Emulate click action button release

I can also confirm that this has fixed the issue.

Will this get backported to 3.24?

(In reply to Jan Niklas Hasse from comment #30)
> I can also confirm that this has fixed the issue.
> Will this get backported to 3.24?

It has already been backported yesterday, I pushed the patch to both master and gnome-3-24.

Ah sorry, didn't notice that. Awesome :) Thank you

When will the fix arrive for Fedora 26 Workstation? I see it's "RESOLVED FIXED" now, but the recent set of updates didn't fix it yet. I'm unfamiliar with this process. Sorry.

> When will the fix arrive for Fedora 26 Workstation? I see it's "RESOLVED
> FIXED" now, but the recent set of updates didn't fix it yet. I'm unfamiliar
> with this process. Sorry.

Oh, right. I forgot I'm in GNOME bugzilla and not Red Hat's. Fedora needs to push the update now. So your job is done. Interesting. Thanks!

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