Seeing this too. Blocker !

same. <esc> does appear to bring the login screen back, however

This should be fixed in clutter 1.13.10

I am seeing this using clutter 1.3.10.

not fixed with clutter 1.3.10. it is only happening for lock on idle here, if I use C-A-L to lock the screen, things behave as expected

(In reply to comment #5)
> not fixed with clutter 1.3.10. it is only happening for lock on idle here, if I
> use C-A-L to lock the screen, things behave as expected

Hmm ok ... any JS errors when this happens?

For reference, affects current gnome-ostree master too, but only sometimes.  I haven't seen it recently.  I've also seen it in a Fedora 18 VM (running on RHEL 6.4).

confirm I see this with clutter 1.3.10 also. I'll check for journalctl output with 1.3.10 soon.

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

Retitling. We're supposed to show the shield on this screen, which is why "Esc" will dismiss it.

Turning on the screensaver through:
gdbus call --session --dest org.gnome.ScreenSaver --object-path /org/gnome/ScreenSaver --method org.gnome.ScreenSaver.SetActive 'true'
won't replicate the problem though.

I'm seeing a similar issue in Ubuntu 13.04 with GNOME Fallback 3.6, so maybe it's a regression deeper in the stack?

Ok.  Before I mention anything else, let me point out:
https://bugzilla.gnome.org/show_bug.cgi?id=696500
which makes debugging this even more confusing as you have different behavior if you're running in a VM versus baremetal.  Boot with gnome.is_vm=0 to work around the VM special casing.

Now, there are *five* actors here:

* gnome-session (SessionIsActive DBus property)
* systemd's logind (backend for SessionIsActive)
* gnome-settings-daemon (power plugin)
* gnome-shell (lock screen, compositor)
* X.org (idletime, via gnome-desktop).  

The relationship between these and the lock screen is rather complicated, and they all communicate.

So first, why is the screen black?  I think (but haven't completely verified) it's because the gsd power plugin has DPMS off'd the monitor.

Now, what's the difference between locking the screen with Control-Alt-L or DBus versus waiting for the timeout?  It's the gnome-session SessionIsActive property, from what I can see.

Still debugging.

It's not gnome-settings-daemon setting the DPMS. You'd see the mouse cursor, backlight on and possibly keyboard backlight on when this happens. So the display is woken up. In fact you should be able to reproduce this with g-s-d's power plugin disabled.

(In reply to comment #13)
> It's not gnome-settings-daemon setting the DPMS. 

Yeah...that seems to be the case.  At the moment I'm guessing this is some sort of redraw bug.  I see gnome-shell receiving XI motion events from the cursor.  I'm guessing the reason the keyboard works is because it causes the shield to raise, which triggers a redraw.

(In reply to comment #14)
> (In reply to comment #13)
> > It's not gnome-settings-daemon setting the DPMS. 
> 
> Yeah...that seems to be the case.  At the moment I'm guessing this is some sort
> of redraw bug.  I see gnome-shell receiving XI motion events from the cursor. 
> I'm guessing the reason the keyboard works is because it causes the shield to
> raise, which triggers a redraw.

Does triggering a redraw by hand (like calling queue_redraw using the dbus eval method) make it work then?

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > It's not gnome-settings-daemon setting the DPMS. 
> > 
> > Yeah...that seems to be the case.  At the moment I'm guessing this is some sort
> > of redraw bug.  I see gnome-shell receiving XI motion events from the cursor. 
> > I'm guessing the reason the keyboard works is because it causes the shield to
> > raise, which triggers a redraw.
> 
> Does triggering a redraw by hand (like calling queue_redraw using the dbus eval
> method) make it work then?

Looks like it - if I attach with gdb from a serial console, and do:

(gdb) p clutter_actor_queue_relayout (clutter_stage_get_default ())

then it wakes up.

(In reply to comment #16)
> 
> (gdb) p clutter_actor_queue_relayout (clutter_stage_get_default ())

Hm, I must have accidentally hit a key - trying again, I can't make it wake up with _redraw or _relayout.

(In reply to comment #17)
> (In reply to comment #16)
> > 
> > (gdb) p clutter_actor_queue_relayout (clutter_stage_get_default ())
> 
> Hm, I must have accidentally hit a key - trying again, I can't make it wake up
> with _redraw or _relayout.

Ok, mouse motion is definitely triggering redraws, I end up in _clutter_stage_do_paint()/cogl_onscreen_swap_buffers().  But we're just not drawing the right thing?

(In reply to comment #18)

> Ok, mouse motion is definitely triggering redraws, I end up in
> _clutter_stage_do_paint()/cogl_onscreen_swap_buffers().  But we're just not
> drawing the right thing?

And inside GDB, I see redraws being queued automatically from the clock changing.  So it's still mysterious to me why pressing a key works...

I have tested in a VM when the screen turns black I cannot activate it unless I do:

gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval 'Main.screenShield._onUserBecameActive();'

_onUserBecameActive() is supposed to be called by the idleMonitor when it thinks that the user is active again.

Actually 
gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval 'Main.screenShield._lightbox.hide();'

is enough ... we don't hide the lightbox when the user moves the mouse ... because _onUserBecameActive does not get called.

Ok yeah, it's definitely the lightbox - which I didn't realize at first was completely black, anyways I'm stupid =)

gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell
--method org.gnome.Shell.Eval 'Main.screenShield._lightbox.hide()' shows everything of course.

So yeah, at this point it does look like a bug in the idle monitor.

Created attachment 239702 [details] [review]
screenshield: HACK

idleMonitor does not like us ...

---

OK this makes it work for me which confirms that this is an idleMonitor bug.

Possibly related: https://bugzilla.gnome.org/show_bug.cgi?id=696522

I'm pretty certain it's not a bug in GnomeIdleMonitor, as g-s-d would have used it to bring back the backlight. Note that when Jasper changed the API  he made it so that the became-active callback will only get called once. You'll need to set up another callback after that.

Ok, yep I think this is a regression from:

commit a9815ae1e9844ac8ae06496981a9ddd23a4a30eb
Author: Giovanni Campagna <gcampagna@src.gnome.org>
Date:   Sat Dec 29 15:24:03 2012 +0100

    ScreenShield: don't animate arrows if the user is idle

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

Because it overwrites the active time idle watch from the other part of the screen shield.  Which is understandable given https://bugzilla.gnome.org/show_bug.cgi?id=696522

Confirmed this small patch fixes it:

@@ -991,9 +1004,6 @@ const ScreenShield = new Lang.Class({
             Mainloop.source_remove(this._arrowAnimationId);
             this._arrowAnimationId = 0;
         }
-
-        if (!this._arrowActiveWatchId)
-            this._arrowActiveWatchId = this.idleMonitor.add_user_active_watch(Lang.bind(this, this._startArrowAnimation));
     },
 
     _stopArrowAnimation: function() {

Let's just revert that for now and work on a better solution for 3.8.1.

That gets my +1

You found a bug (or a limitation, depending on what Jasper meant in this new API) in GnomeIdleMonitor:
        g_hash_table_insert (monitor->priv->watches,
                             GUINT_TO_POINTER (watch->id),
                             watch);

You can only have one became-active callback per GnomeIdleMonitor object. This should be fixable within the existing API, as long as the current behaviour wasn't meant.

Created attachment 239733 [details] [review]
idle-monitor: Allow multiple "became-active" watches

UNTESTED

We were using the same identifier for all the "became-active"
requests, even though some code (such as the screenShield in
gnome-shell) would expect each _add_user_active_watch() to result
in a separate callback.

This should fix a black screen in gnome-shell when the screenShield
would have been expected.

(In reply to comment #31)
> Created an attachment (id=239733) [details] [review]
> idle-monitor: Allow multiple "became-active" watches

That's what bug 696522 is supposed to fix, no?

Yes.

Created attachment 239827 [details] [review]
screenshield: Share watch callback

Currently gnome-desktop only supports one user active callback, we need two so
share the one that we have.

Review of attachment 239827 [details] [review]:

You're leaving around this bit of code:

        if (this._becameActiveId != 0) {
            this.idleMonitor.remove_watch(this._becameActiveId);
            this._becameActiveId = 0;
        }

right?

My preference here is to fix gnome-desktop, since that's the clearly correct thing to do for git master.

Created attachment 239833 [details] [review]
screenshield: Share watch callback

Currently gnome-desktop only supports one user active callback, we need two so
share the one that we have.

---

Yeah removed that now ... yeah I prefer to fix gnome-desktop as well.
This is just the "fallback plan" if we consider fixing gnome-desktop to
be to invasive.

So https://bugzilla.gnome.org/show_bug.cgi?id=696522 is now pushed to master.

I'm waiting on gnome-ostree to output the latest build so I can test; if that pans out, I recommend we go with backporting the g-d patches to 3.8.

Ok, after some testing I'm happy enough with the patches from bug 696522.

However, there is another bug...but we can ship with this one and fix it in 3.8.1.

what is the other bug ?

(In reply to comment #39)
> what is the other bug ?

I haven't debugged this yet enough to file, but basically after we wake up from user activity in the lock screen, we never go back to sleep.

sounds better than the opposite

Let's consider this fixed for now.

(In reply to comment #42)
> Let's consider this fixed for now.

Er... comment 40 ? Or do we consider this a different bug?

(In reply to comment #43)
> Er... comment 40 ? Or do we consider this a different bug?

No.

Review of attachment 239833 [details] [review]:

We decided to just fix gnome-desktop.

Colin, have you done any additional investigation on this?

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

No additional work has been done on this, so closing.