View Issue Details

IDProjectCategoryView StatusLast Update
0002513Kali Linux[All Projects] Kali Package Bugpublic2020-12-01 10:48
Reporterrhertzog Assigned Torhertzog  
Status resolvedResolutionfixed 
Product Version2.0 
Target Version2016.1Fixed in Version 
Summary0002513: Lockscreen doesn't always hide the menus and the dock

This is probably a bug in one of the GNOME Shell extension we use and/or modify. It would be nice to identify the problematic shell extension (if any) by disabling them all and enabling only one at a time... or by disabling only one at a time and seeing when the problem occurs or not.
Steps To ReproduceIt's not clear how to reproduce this issue systematically. If someone can identify exactly how to trigger this it would be nice.


duplicate of 0002657 closedrhertzog menu bar visible from lock screen + show application works in lock screen 
has duplicate 0003948 closedrhertzog Full access to applications and menu bar without logging in. 



2015-09-02 07:32

administrator   ~0003868

Some upstream tickets which might be related:

One should provide the output of Gnome Shell after having experienced the issue. You can find its output in the journal (sudo journalctl -r_COMM=gnome-session)


2015-12-14 15:21

administrator   ~0004404

While I used to reproduce it sometimes with sana, I have not been able to reproduce it with kali-rolling so far.

g0tmi1k, what about you?


2016-05-08 18:36

reporter   ~0005197

i think i can reproduce this in kali-rolling. i think it's the same issue. if you want me to create a new bug though i'm happy to.

i'll post whatever info i can, but the journalctl command above responds with a "no entries" message, so i'm guessing about what might be important.

it's actually fairly simple to reproduce this with my setup.

repro steps:
1. make the dock auto-hide
2. move the mouse cursor over the dock
3. close the laptop lid so it goes to sleep
4. open the lid, and wait for it to wake up
5. dock still visible, applications can be opened.

things of note:
- the dock loses its ability to auto-hide until the user opens an application from it, and the screen is unlocked
- firefox, terminal, chrome, vmware-player (with a windows 10 insider preview build) were all running when this happened
- i opened it up in the morning and noticed the dock exposed on the lock screen. directly before going to sleep the night before (may 7th 2016) the last thing i did was apt-get update and apt-get dist-upgrade.

lenovo thinkpad w530 - not sure which build exactly, i got it 2nd hand and all the stickers are missing.

i posted a video on youtube of this behavior. the video is intentionally not very descriptive and the video is only viewable if you have the link.

thanks for looking into it. this seems dangerous to me.

please let me know if there's any more info i can provide!


2017-04-06 08:30

manager   ~0006562

I have seen this problem and I have this message when I tried to unlock:

avril 06 10:08:50 kali-dev gnome-terminal-[28697]: Allocating size to GtkScrollbar 0x55a07f55e390 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
avril 06 10:08:08 kali-dev gnome-shell[1002]: JS ERROR: Exception in callback for signal: updated: Error: Type name EasyScreenCastSettingsWidget is already registered


2017-04-06 08:54

manager   ~0006563

Even earlier the problem seems to have appeared during a dist-upgrade and the initial message shown was this one:

avril 06 09:14:55 kali-dev gnome-shell[1002]: JS ERROR: Error: Type name EasyScreenCastSettingsWidget is already registered


2017-04-06 10:22

manager   ~0006564

maybe it's related to


2017-04-07 12:03

administrator   ~0006568

The initial trigger seems to be "dconf update" (as run in kali-menu's postinst) which triggers some sort of internal reload in gnome-shell.


2017-04-25 15:31

manager   ~0006589

fixed in gnome-shell-extension-easyscreencast version 0.10-0kali1


2017-04-25 16:07

reporter   ~0006590

FWIW I found out that this can be triggered by changing the key in gsettings. The dconf update call after changing /etc/dconf/db/local.d/kali-* is somehow triggering an update of that key, for some reason.

After fixing the EasyScreenCast extension I have investigated the gnome-shell problem, since it shouldn't fail even if an extension fails to reload. That's now forwarded upstream at:

There's a patch that makes this bug not happen even with the broken EasyScreenCast extension - then the broken extension gets disabled but none of the others get enabled on the lock screen. That'd be good to avoid this problem in the future, but let's see what upstream says about this patch.

Issue History

Date Modified Username Field Change
2015-08-13 06:33 rhertzog New Issue
2015-08-13 06:33 rhertzog Status new => assigned
2015-08-13 06:33 rhertzog Assigned To => rhertzog
2015-09-02 07:32 rhertzog Note Added: 0003868
2015-09-14 14:30 g0tmi1k Relationship added duplicate of 0002657
2015-12-14 15:21 rhertzog Note Added: 0004404
2015-12-14 15:22 rhertzog Target Version 2.0 => 2016.1
2016-05-08 18:36 badmacktuck Note Added: 0005197
2017-04-05 07:37 rhertzog Relationship added has duplicate 0003948
2017-04-06 08:30 sbrun Note Added: 0006562
2017-04-06 08:54 sbrun Note Added: 0006563
2017-04-06 10:22 sbrun Note Added: 0006564
2017-04-07 12:03 rhertzog Note Added: 0006568
2017-04-25 15:31 sbrun Status assigned => resolved
2017-04-25 15:31 sbrun Resolution open => fixed
2017-04-25 15:31 sbrun Note Added: 0006589
2017-04-25 15:59 rhertzog Status resolved => assigned
2017-04-25 16:07 pochu Note Added: 0006590
2017-04-25 17:26 rhertzog Status assigned => resolved
2020-12-01 10:48 g0tmi1k Priority high => normal