there were only 3 changes between 3.4.1 and 3.4.2 and it's hard for me to explain how any of those changes could cause this sort of issue.

What distribution are you using?  Do you know if they apply any distro patches?

If you're building from source, can you try reverting the three patches 1 by 1 and identifying the culprit?

I have the same issues, using Arch Linux.  Under 3.4.2, the following will happen:
- Locking only blanks the primary display.
- Locking with more than one virtual workspace active causes gnome-shell to spin at 100% CPU, and unlock dialog will never appear. Have to kill the gnome session from a console to recover.

When I get some time later, I'll try to build with the patches and see what happens.

My distro is also Arch (x86_64), as far as I see there are no patches applied by Arch for this package.

I'll attach the debug output of both 3.4.1 and 3.4.2 versions.

Created attachment 218163 [details]
debug output

debug output from versions 3.4.2 and 3.4.1

Another report of this issue in Bug 679246.

I am having the same issue on Arch (x64_64) with version 3.4.2 and a dual monitor setup using the nouveau driver. When waking up the system, the secondary screen shows, the primary stays blank and there is no login dialog.

I am having a very similar issue on Arch (x86_64) since upgrade from 3.4.1 to 3.4.2.

In my case, it's not a dual monitor setup, but I am using a tiling window manager (xmonad) with gnome panel + session. When I lock the screen, the "session locked" screen appears as a single window in its own tile; the other tiles are still visible and react to the mouse. Keyboard input is trapped by the password dialog, however if I click some icon in the status bar which triggers a workspace switch, I even get the keyboard back, which makes this a serious security issue.

Since no relevant packages other than gnome-screensaver were updated at that time, I am pretty sure the issue has something to do with this package. It is interesting, however, that all affected users seem to use arch linux ...

I only see comments about being affected by people using Arch Linux so far...

As written before: If you're building from source, can you try reverting the three patches 1 by 1 and identifying the culprit?

Also, is everybody using Nvidia hardware? 
All Nouveau driver, or the proprietary one?

I am using the intel driver; tested both xf86-video-intel-{sna,uxa}.

Hi,
We do not alter or modify the sources in any way. Since you guys think is an arch issue(which is not the case), I have created this packages for testing:

gnome-screensaver 3.4.2-1.1 reverting only the commit " window: don't use GtkRC to override drawing area's background"

gnome-screensaver 3.4.2-1.2 reverting only the commit " window: only show panel on primary head"

http://pkgbuild.com/~ioni/gnome-screensaver

Please test this packages and let us know which one works and which doesn't.

I am using the intel (i915) driver on Arch (x64_64) with version 3.4.2 and a dual
monitor setup.  I am also experiencing this bug.

Ionut, thanks for creating the packages. In my case (single monitor, xmonad),

- bug is gone with 3.4.2-1.1
- bug is present with 3.4.2-1.2

(In reply to comment #12)
> In my case (single monitor, xmonad),
> - bug is gone with 3.4.2-1.1
> - bug is present with 3.4.2-1.2

Which means that likely http://git.gnome.org/browse/gnome-screensaver/commit/?id=fc6695ecb9023b7049fa0dba91276d39f983425e triggered this, which was about fixing bug 677793.

halfline: ping?


(In reply to comment #10)
> Since you guys think is an arch issue(which is not the case)

Oh I didn't say or mean that, just summarized previous comments so far. :)

Expieriencing similiar issue but it more like #679246 and comment 2: one Monitor stays visible and the other turns black. cant see the password-box nor enter the password blind. have to restart gdm.
arch with gnome-screensaver 3.4.2-1

Bug is fixed for me using Ionut's 3.4.2-1.1

Arch Linux x86_64, all packages up to date

Dual Head, Nouveau driver.

Left (main) screen would remain black with just the date/time visible. 
Right screen would sometimes remain semi-usable:
   could create a new firefox tab by clicking on the plus with the mouse
   could close windows by clicking on the X
   could not resize or shade windows
   could not type using the keyboard

Okay, I've reverted the patch for now and done a 3.4.3 release.

Sad to say, but in 3.4.3 the problem is still here. 

Q: Am I the only one that can confirm?

I can confirm this. I'm using arch linux x86_64 and the latest update to 3.4.3 didn't solve the problem for me.

I can also confirm this issue is still present in 3.4.3 on Arch Linux x86_64. It isn't constantly reproducible however, it worked twice correctly, hiding the second monitor but then returned to the erroneous behaviour.

Yup still there. The first two times I tried it didn't crash gnome shell but left the secondary monitor unprotected. Tried again and here it goes freezing again.

Can confirm erroneous behaviour with arch and 3.4.3. 
using both the intel and on another pc the ati open source drivers

yes same issue on 3.4.3 (obviously still Arch [x86_64] ;-)

Ray, it appears you have reverted the wrong patch [fc6695ec] by mistake ... the 2+ users above confirmed Ionut's "1.1" pkg, which reverted 43ee32ed (window: don't use GtkRC to override drawing area's background).

i can confirm this behavior:
 - commit fc6695ec (NO ISSUE)
    * window: only show panel on primary head)
 - commit 43ee32ed (AUTHDIALOG MISSING/BLACK; ONLY LOCKS 1/2 SCREEN)
    * window: don't use GtkRC to override drawing area's background

however, thanks to some comments and reading source, i found addtl details:
 - both initially fade to 100% black
 - non primary screen made visible again [trans] the SAME MOMENT top-panel is painted
 - if mouse is on NON-PRIMARY output [trans], auth-dialog WILL NOT be visible upon activation (on keypress, etc; output still transparent)
 - if mouse is on PRIMARY screen [black], auth-dialog WILL be made visible when activated (keypress, etc; output displays auth-dialog as expected)
 - however, after some pressing esc and moving mouse, it's possible to get into situation where GS thinks the incorrect output is primary, thereby reversing the roles for a time (IOW, mouse@non-primary -> visible, mouse@primary -> invisible)
 - aside from the initial fading, at NO POINT IN TIME will the non-primary output EVER switch from transparent (user desktop is visible!) to black/auth-dialog.

... after realizing the intended primary-only behaviour, i am now capable of restoring my desktop even when faced with the glitches onlined by this bug. it seems nothing is locked or broken per se, you simply cannot see the dialog if your mouse happens to be on the transparent [non-primary] monitor, AND sometimes GS gets the two mixed up.

i tried to crank a patch quick but i'm short on time and unfamiliar with GTK API :-(, but hopefully i've shed additional light. thanks!

well i lied ... there are times i actually lock, or, as it seems, the mouse is incapable of being seen and/or focusing on the underlying windows (though i have no idea really, as they are either both black or one-trans/one-black).  happens more when apps are open on desktop; when i tested earlier i had zero apps open.

either way, it's super annoying ;-), and it's * definitely* 43ee32ed causing all the headache ... once that goes away [revert] ... life moves forward again.

can we get a respin of the last point release? this bug appears CONFIRMED, and is a simple regression to fix.  however, wrong patch was reverted (AFAICT that patch can be reapplied), thus it's NOT fixed ...

i have 4 machines with dual+ monitors (work/home/etc), various hardware, and every single one of them is affected :-(

Gentoo users are also reporting that commit 43ee32ed is the one that causes problems on dual-head: https://bugs.gentoo.org/show_bug.cgi?id=425070#c28

3.4.3 had reverted the wrong commit and therefore is still broken.

I can also confirm this bug under Arch Linux with version 3.4.3. For now I have just downgraded the package, but reverting the correct patch seems to be the best solution.

The only explanation I can come up with is that realizing the drawing area early is causing issues.  Under normal conditions it gets realized right before it's mapped to the screen.  It's not immediately obvious to me why that would be a problem, and try as I might, I can't reproduce what you guys are seeing, so what I'm going to do is:

1) revert the reversion and revert the offending commit and do another 3.4 release
2) add a new commit that changes the gtk_widget_realize call to handler to the "realize" signal instead, so we don't force things to happen early but instead just react to them happening.  Then I'll do a 3.5 release

Created attachment 219060 [details] [review]
gs-window-x11: defer setting bg color until realization

commit 43ee32edaddb9b9b9f4b43c47ca73d7b4eea9fae changed
the drawing area associated with each monitors screensaver
window to get realized early.

That change is seemingly causing problems for users.

This commit stops preemptively realizing the drawing areas,
and instead makes the background color settings get applied
reactively in response to realization.

http://bugzilla.gnome.org/show_bug.cgi?id=679441

Comment on attachment 219060 [details] [review]
gs-window-x11: defer setting bg color until realization

okay i've pushed that patch to master

I've released 3.4.4 and 3.5.4.  I'd appreciate feedback on if they make the situation better.

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

I can confirm that both 3.4.4 and 3.5.4 fix this bug under Arch Linux. With either version, both monitors get locked properly.

I can also confirm that 3.5.4 fixes the bug under the following OS. Thanks for the great work!

Linux 3.4.4-3-ARCH x86_64

Me happy :)
Confirming and closing this issue as fixed. tested version 3.4.4
+1 halfline!

Issue is resolved with gnome-screensaver 3.4.4 on Linux 3.4.5-1-ARCH. Both monitors get locked and unlocked properly. Thanks for the effort.