chromeos: Add _CHROME_LOGGED_IN property on root window.

chromeos: Add _CHROME_LOGGED_IN property on root window.

This gets set to either 1 or 0 depending on whether the user
is currently logged in or not.  I'm doing this as a step towards
using the same window manager process during and after login;
this will let the WM know which log file it should be using, for
instance.

BUG=chromium-os:2790
TEST=tried it, and will add an autotest for this soon

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

[Chris Masone, 2010-05-19 17:22:08]

On 2010/05/19 17:18:24, Daniel Erat wrote:
> 

drive-by:

How will this work in the event that the WM and/or chrome crash and get
restarted?  There does exist a mechanism by which the session manager tells a
respawned-chrome that a user is already logged in...would chrome need to set
this property again in that event?  The flag that gets passed is called
something like --login-user, so you could look around to see where that's
handled and make it set this property there as well, if it'll be needed.

[Daniel Erat, 2010-05-19 17:24:58]

On 2010/05/19 17:22:08, cmasone wrote:
> On 2010/05/19 17:18:24, Daniel Erat wrote:
> drive-by:
> 
> How will this work in the event that the WM and/or chrome crash and get
> restarted?  There does exist a mechanism by which the session manager tells a
> respawned-chrome that a user is already logged in...would chrome need to set
> this property again in that event?  The flag that gets passed is called
> something like --login-user, so you could look around to see where that's
> handled and make it set this property there as well, if it'll be needed.

That's why I used a property; it'll persist as long as X is running.

[Daniel Erat, 2010-05-19 17:26:31]

On 2010/05/19 17:24:58, Daniel Erat wrote:
> On 2010/05/19 17:22:08, cmasone wrote:
> > On 2010/05/19 17:18:24, Daniel Erat wrote:
> > drive-by:
> > 
> > How will this work in the event that the WM and/or chrome crash and get
> > restarted?  There does exist a mechanism by which the session manager tells
a
> > respawned-chrome that a user is already logged in...would chrome need to set
> > this property again in that event?  The flag that gets passed is called
> > something like --login-user, so you could look around to see where that's
> > handled and make it set this property there as well, if it'll be needed.
> 
> That's why I used a property; it'll persist as long as X is running.

Followup: Is it possible for Chrome to crash after the login manager
thinks the user is logged in but before Chrome sets the property?  I'll
set it there too if you're concerned about that.

[Daniel Erat, 2010-05-19 17:26:48]

On 2010/05/19 17:26:31, Daniel Erat wrote:
> On 2010/05/19 17:24:58, Daniel Erat wrote:
> > On 2010/05/19 17:22:08, cmasone wrote:
> > > On 2010/05/19 17:18:24, Daniel Erat wrote:
> > > drive-by:
> > > 
> > > How will this work in the event that the WM and/or chrome crash and get
> > > restarted?  There does exist a mechanism by which the session manager
tells
> a
> > > respawned-chrome that a user is already logged in...would chrome need to
set
> > > this property again in that event?  The flag that gets passed is called
> > > something like --login-user, so you could look around to see where that's
> > > handled and make it set this property there as well, if it'll be needed.
> > 
> > That's why I used a property; it'll persist as long as X is running.
> 
> Followup: Is it possible for Chrome to crash after the login manager
> thinks the user is logged in but before Chrome sets the property?  I'll
> set it there too if you're concerned about that.

s/login manager/session manager/

[Chris Masone, 2010-05-19 17:37:36]

On 2010/05/19 17:26:48, Daniel Erat wrote:
> On 2010/05/19 17:26:31, Daniel Erat wrote:
> > On 2010/05/19 17:24:58, Daniel Erat wrote:
> > > On 2010/05/19 17:22:08, cmasone wrote:
> > > > On 2010/05/19 17:18:24, Daniel Erat wrote:
> > > > drive-by:
> > > > 
> > > > How will this work in the event that the WM and/or chrome crash and get
> > > > restarted?  There does exist a mechanism by which the session manager
> tells
> > a
> > > > respawned-chrome that a user is already logged in...would chrome need to
> set
> > > > this property again in that event?  The flag that gets passed is called
> > > > something like --login-user, so you could look around to see where
that's
> > > > handled and make it set this property there as well, if it'll be needed.
> > > 
> > > That's why I used a property; it'll persist as long as X is running.
> > 
> > Followup: Is it possible for Chrome to crash after the login manager
> > thinks the user is logged in but before Chrome sets the property?  I'll
> > set it there too if you're concerned about that.
> 
> s/login manager/session manager/

It's possible, yeah.  The StartSession() call just above your call is what tells
the session manager that someone's logged in.  It's a dbus call, so it's
possible that something could go wrong in sending back the response, parsing the
response, or in that call to the UserManager or something.

[Daniel Erat, 2010-05-19 22:19:37]

On 2010/05/19 17:37:36, cmasone wrote:
> On 2010/05/19 17:26:48, Daniel Erat wrote:
> > On 2010/05/19 17:26:31, Daniel Erat wrote:
> > > On 2010/05/19 17:24:58, Daniel Erat wrote:
> > > > On 2010/05/19 17:22:08, cmasone wrote:
> > > > > On 2010/05/19 17:18:24, Daniel Erat wrote:
> > > > > drive-by:
> > > > > 
> > > > > How will this work in the event that the WM and/or chrome crash and
get
> > > > > restarted?  There does exist a mechanism by which the session manager
> > tells
> > > a
> > > > > respawned-chrome that a user is already logged in...would chrome need
to
> > set
> > > > > this property again in that event?  The flag that gets passed is
called
> > > > > something like --login-user, so you could look around to see where
> that's
> > > > > handled and make it set this property there as well, if it'll be
needed.
> > > > 
> > > > That's why I used a property; it'll persist as long as X is running.
> > > 
> > > Followup: Is it possible for Chrome to crash after the login manager
> > > thinks the user is logged in but before Chrome sets the property?  I'll
> > > set it there too if you're concerned about that.
> > 
> > s/login manager/session manager/
> 
> It's possible, yeah.  The StartSession() call just above your call is what
tells
> the session manager that someone's logged in.  It's a dbus call, so it's
> possible that something could go wrong in sending back the response, parsing
the
> response, or in that call to the UserManager or something.

Another look?  I moved the call to set the property to 1 to
UserManager::UserLoggedIn(), which gets called when the login-user flag is
passed and from the same spot in LoginUtilsImpl::CompleteLogin() where I was
calling it before (and from nowhere else).

[Chris Masone, 2010-05-19 22:31:05]

LGTM