GNOME Bugzilla – Bug 763886
Click on activities doesn't bring overview once the system date/time is set to past
Last modified: 2018-07-14 08:58:49 UTC
Once the system clock date/time is set to some time from the past (even one minute) relative to the current time, nothing happens when Activities is clicked. Anyway, once I press the <super> key, it begins to behave normally (Overview is shown) on click. I haven't checked this on a system with wrong time at startup (Like in the case of a system without BIOS battery).
Activities doesn't get activated even for a difference of 10 seconds. (Previously, this happened for even 1 second, but I can't reproduce that now.) time was set 10s back by: sudo date -s "10 seconds ago" This was checked disabling auto update of time and time zone.
Reproduced on Tails 3.4 (GNOME Shell 3.22.3, https://labs.riseup.net/code/issues/14250), current Debian sid (GNOME Shell 3.26.2-2) and Fedora-Workstation-Live-x86_64-27-1.6.iso, both when changing the time with `date` in a Terminal, and when setting it in GNOME control center. FWIW it's one of the hottest topic reported by the Tails help desk: it affects Tails users whose RTC is set to local time and who are in a timezone >> UTC, much more than most other systems because we have to do unorthodox things to set the system clock to the current UTC time&date at every boot (https://tails.boum.org/contribute/design/Time_syncing/).
Additional info: 1. This does not happen every single time: we've seen GNOME sessions during which it works flawlessly, sessions during which every "set clock 1 hour in the past" breaks the Activities & Applications menu every time, and sessions with mixed results. 2. We've tested this in pristine GNOME Shell without any custom extension (and then the bug applies to the Activities button) and on GNOME Shell + the apps-menu and places-menu extensions (and then the bug applies to the Applications button). 3. As Mohammed Sadiq reported, pressing Super fixes the behaviour of the Activities/Applications button. 4. When the places-menu extension is enabled, some users report that clicking the Places button and then moving the mouse to the Applications button fixes the apps menu. 5. Wrt. "nothing happens when Activities is clicked", this does not exactly match what I'm observing: I see the blue border under the Activities button that usually indicates that the Activities view is open, so something definitely happened; but indeed that's all that visibly happens when pressing the Activities button.
Created attachment 366835 [details] [review] overview: Use monotonic time to check for consecutive activations We don't toggle the overview if the request happens too close to the last activation, to filter out double-clicks or activation by both the hot corner and a click. However as the check is based on the real time, the check breaks if the system clock moves backwards and the last activations appears to be in the future. Fix this by using monotonic time which is guaranteed to only move forward. Untested, but pretty sure that's what's going on.
Review of attachment 366835 [details] [review]: I've tested this patch on current Debian sid and could not reproduce the bug anymore :) Florian's reasoning totally makes sense and the patch looks good to me.
Hi Florian! Is there anything I can do (except being patient :) to help ensure your fix is applied to Git? Also, any chance it makes its way into a 3.22.x maintenance release? Meanwhile, FYI I've cherry-picked it for Tails and it'll go live in our next release on Tuesday. Thanks again!
(In reply to intrigeri from comment #6) > Is there anything I can do (except being patient :) to help > ensure your fix is applied to Git? No, sorry - I'm waiting for review from some fellow dev :-) > Also, any chance it makes its way into a 3.22.x maintenance release? No, as far as upstream is concerned, only 3.26.x is still supported.
Comment on attachment 366835 [details] [review] overview: Use monotonic time to check for consecutive activations Uploaded the patch to gitlab: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/42
The patch landed in gitlab, so I missed closing this.