Some upstream tickets which might be related:
https://bugzilla.gnome.org/show_bug.cgi?id=693292
https://bugzilla.gnome.org/show_bug.cgi?id=709806

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)

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?

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.

hardware:
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.

https://www.youtube.com/watch?v=UNiLo9RERBo&feature=youtu.be

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

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

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
GObjectMeta<._construct@resource:///org/gnome/gjs/modules/overrides/GObject.js:145
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:213
@/usr/share/gnome-shell/extensions/[email protected]/prefs.js:609
@/usr/share/gnome-shell/extensions/[email protected]/convenience.js:34
@/usr/share/gnome-shell/extensions/[email protected]/extension.js:34
initExtension@resource:///org/gnome/shell/ui/extensionSystem.js:220
enableExtension@resource:///org/gnome/shell/ui/extensionSystem.js:109
enableAllExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:311
enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:310
_sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:338
_emit@resource:///org/gnome/gjs/modules/signals.js:124
SessionMode<._sync@resource:///org/gnome/shell/ui/sessionMode.js:205
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
SessionMode<.popMode@resource:///org/gnome/shell/ui/sessionMode.js:174
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
ScreenShield<._continueDeactivate@resource:///org/gnome/shell/ui/screenShield.js:1200
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
ScreenShield<.deactivate/<@resource:///org/gnome/shell/ui/screenShield.js:1185
AuthPrompt<.finish@resource:///org/gnome/shell/gdm/authPrompt.js:506
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
UnlockDialog<.finish@resource:///org/gnome/shell/ui/unlockDialog.js:147
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
ScreenShield<.deactivate@resource:///org/gnome/shell/ui/screenShield.js:1184
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
ScreenShield<._init/</<@resource:///org/gnome/shell/ui/screenShield.js:536
_emit@resource:///org/gnome/gjs/modules/signals.js:124
_convertToNativeSignal@resource:///org/gnome/gjs/modules/overrides/Gio.js:129

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
GObjectMeta<._construct@resource:///org/gnome/gjs/modules/overrides/GObject.js:145
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:213
@/usr/share/gnome-shell/extensions/[email protected]/prefs.js:609
@/usr/share/gnome-shell/extensions/[email protected]/convenience.js:34
@/usr/share/gnome-shell/extensions/[email protected]/extension.js:34
initExtension@resource:///org/gnome/shell/ui/extensionSystem.js:220
enableExtension@resource:///org/gnome/shell/ui/extensionSystem.js:109
_onVersionValidationChanged/<@resource:///org/gnome/shell/ui/extensionSystem.js:284
_onVersionValidationChanged@resource:///org/gnome/shell/ui/extensionSystem.js:283

maybe it's related to
https://github.com/EasyScreenCast/EasyScreenCast/issues/46

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.

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

FWIW I found out that this can be triggered by changing the org.gnome.shell.disable-extension-version-validation 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:

https://bugzilla.gnome.org/show_bug.cgi?id=781728

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.