chromeos: Remove references to UnlockScreenFailed signal.

chromeos: Remove references to UnlockScreenFailed signal.

This looks like it was initially added to handle D-Bus
signals emitted by powerd when we failed to unlock the
screen for some reason, but there are no references to the
signal in either the power manager or session manager source
now, and I can't find any code in Chrome to emit the signal
either.  Code Search doesn't show any references to
"UnlockScreenFailed" outside of the chromium tree and
system_api.

BUG=chromium-os:24003
TEST=manual: still able to lock and unlock the screen; automatic locking on suspend works too


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=145418

[oshima, 2012-07-03 23:14:56]

On 2012/07/03 20:10:21, Daniel Erat wrote:

I thought I replied earlier, but seems like I didn't hit send.

I think this protocol was added to give powered a chance to reject lock request,
for edge case like you unlock the screen but at the same time, you close the
lid.

(it may end up being in unlock state when the lid is opened)

I think this was never implemented in powerd side and  that's why you coudln't
find it. If you think that's not important, please feel free to remove it.

[Daniel Erat, 2012-07-03 23:29:19]

On 2012/07/03 23:14:56, oshima wrote:
> On 2012/07/03 20:10:21, Daniel Erat wrote:
> 
> I thought I replied earlier, but seems like I didn't hit send.
> 
> I think this protocol was added to give powered a chance to reject lock
request,
> for edge case like you unlock the screen but at the same time, you close the
> lid.
> 
> (it may end up being in unlock state when the lid is opened)
> 
> I think this was never implemented in powerd side and  that's why you coudln't
> find it. If you think that's not important, please feel free to remove it.

If it's important, it should be implemented in a different way that doesn't make
the common screen locking path complicated (e.g. the session manager shouldn't
accept unlock requests after we start suspending, and the power manager should
send a lock request to the session manager just before it actually suspends).  A
lot of time was spent recently debugging screen lock bugs; they would've been
easier to track down if Chrome were just sending requests directly to the
session manager.

[oshima, 2012-07-03 23:42:37]

forgot to stamp. LGTM

On 2012/07/03 23:29:19, Daniel Erat wrote:
> On 2012/07/03 23:14:56, oshima wrote:
> > On 2012/07/03 20:10:21, Daniel Erat wrote:
> > 
> > I thought I replied earlier, but seems like I didn't hit send.
> > 
> > I think this protocol was added to give powered a chance to reject lock
> request,
> > for edge case like you unlock the screen but at the same time, you close the
> > lid.
> > 
> > (it may end up being in unlock state when the lid is opened)
> > 
> > I think this was never implemented in powerd side and  that's why you
coudln't
> > find it. If you think that's not important, please feel free to remove it.
> 
> If it's important, it should be implemented in a different way that doesn't
make
> the common screen locking path complicated (e.g. the session manager shouldn't
> accept unlock requests after we start suspending, and the power manager should
> send a lock request to the session manager just before it actually suspends). 
A
> lot of time was spent recently debugging screen lock bugs; they would've been
> easier to track down if Chrome were just sending requests directly to the
> session manager.

I agree. I actually filed a request to move locking logic to session manager
(crosbug.com/3987)
but it's been forgotten...

[commit-bot: I haz the power, 2012-07-03 23:45:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/derat@chromium.org/10703081/1

[commit-bot: I haz the power, 2012-07-04 01:16:19]

Change committed as 145418