Respect CHROME_USER_DATA_DIR in start-up scripts.

Respect CHROME_USER_DATA_DIR in start-up scripts.

This change allows CHROME_USER_DATA_DIR to override the default profile location
is Chrome is launched via a start-up script. The behaviour is unchanged if that
environment variable is not set.

BUG=351002
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=260461

[Jamie, 2014-03-10 21:29:22]

PTAL.

Is there a build target I can use to generate a suitable .deb so that I can test
this?

[Paweł Hajdan Jr., 2014-03-11 18:11:13]

Sorry, I don't understand the need for this.

Why not just use the command-line flag?

Also the comment when that env variable is used seems inaccurate:

// On Linux, Chrome does not support running multiple copies under different
// DISPLAYs, so the profile directory can be specified in the environment to
// support the virtual desktop use-case.

I'm not aware of problems with running under multiple displays (provided each
copy is using a different user data dir of course).

[Jamie, 2014-03-11 18:57:53]

On 2014/03/11 18:11:13, Paweł Hajdan Jr. wrote:
> Sorry, I don't understand the need for this.
> 
> Why not just use the command-line flag?
> 
> Also the comment when that env variable is used seems inaccurate:
> 
> // On Linux, Chrome does not support running multiple copies under different
> // DISPLAYs, so the profile directory can be specified in the environment to
> // support the virtual desktop use-case.
> 
> I'm not aware of problems with running under multiple displays (provided each
> copy is using a different user data dir of course).

That's exactly the problem. When using Chromoting, the user has two
desktops--the physical one and the virtual one--with two different DISPLAYs. We
set CHROME_USER_DATA_DIR in the virtual one so that all the shortcuts,
command-line aliases etc. that the user has set up will work correctly. Asking
the user to specify a command-line flag inside the virtual session would mean
they'd need separate desktop profiles for the two cases, which seems
unreasonable.

The original change was motivated by lots of bug reports from users confused
that running Chrome inside the virtual desktop appears to do nothing (in fact it
has opened a new window on their console, but they don't see that). Worse, some
people have Chrome set to auto-start in their profile; those users ended up in a
situation whereby Chrome would appear not to run on the console because it was
tied to the virtual session at boot-time. This change just extends the same
logic to the start-up scripts.

[Jamie, 2014-03-11 19:27:50]

On 2014/03/11 18:57:53, Jamie wrote:
> On 2014/03/11 18:11:13, Paweł Hajdan Jr. wrote:
> > Sorry, I don't understand the need for this.
> > 
> > Why not just use the command-line flag?
> > 
> > Also the comment when that env variable is used seems inaccurate:
> > 
> > // On Linux, Chrome does not support running multiple copies under different
> > // DISPLAYs, so the profile directory can be specified in the environment to
> > // support the virtual desktop use-case.
> > 
> > I'm not aware of problems with running under multiple displays (provided
each
> > copy is using a different user data dir of course).
> 
> That's exactly the problem. When using Chromoting, the user has two
> desktops--the physical one and the virtual one--with two different DISPLAYs.
We
> set CHROME_USER_DATA_DIR in the virtual one so that all the shortcuts,
> command-line aliases etc. that the user has set up will work correctly. Asking
> the user to specify a command-line flag inside the virtual session would mean
> they'd need separate desktop profiles for the two cases, which seems
> unreasonable.
> 
> The original change was motivated by lots of bug reports from users confused
> that running Chrome inside the virtual desktop appears to do nothing (in fact
it
> has opened a new window on their console, but they don't see that). Worse,
some
> people have Chrome set to auto-start in their profile; those users ended up in
a
> situation whereby Chrome would appear not to run on the console because it was
> tied to the virtual session at boot-time. This change just extends the same
> logic to the start-up scripts.

After re-reading the comment you mention, I agree that it's a little confusing.
It should really be talking about "windows", not "copies", and be explicit that
it's only true if the same profile directory is being used.

[Jamie, 2014-03-17 18:41:30]

Ping.

[Paweł Hajdan Jr., 2014-03-20 19:16:17]

Sorry, I'm still confused.

Does the user need to specify CHROME_USER_DATA_DIR manually? Whatever specifies
it, it can specify a command-line flag instead it seems.

[Jamie, 2014-03-20 19:23:57]

On 2014/03/20 19:16:17, Paweł Hajdan Jr. wrote:
> Sorry, I'm still confused.
> 
> Does the user need to specify CHROME_USER_DATA_DIR manually? Whatever
specifies
> it, it can specify a command-line flag instead it seems.

The Chromoting host start-up script specifies the environment variable before it
starts the desktop session, which means that it's inherited by all processes in
that session, including Chrome. It can't specify the command-line flag because
it doesn't run Chrome. Chrome will be run at some later point, perhaps via a
command-line entered by the user or perhaps by a shortcut link on the desktop;
in either case, it's not reasonable to expect the user to have to remember to
use a different command-line or short-cut--everything should just work.

Feel free to set up a quick VC if you think this would be easier to understand
if I explained it face-to-face.

[Paweł Hajdan Jr., 2014-03-24 17:22:58]

Please see https://code.google.com/p/chromium/issues/detail?id=264789 for
instructions about building official packages.

The actual launcher script is
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/installer/l...

[Jamie, 2014-03-25 19:36:50]

On 2014/03/24 17:22:58, Paweł Hajdan Jr. wrote:
> Please see https://code.google.com/p/chromium/issues/detail?id=264789 for
> instructions about building official packages.
> 
> The actual launcher script is
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/installer/l...

Thanks for the pointer. I've updated the CL to modify that script instead of the
two build.sh scripts. When I build linux_packages_stable, and examine the
resulting .deb file, I see my change in opt/google/chrome/google-chrome, but not
in usr/bin/google-chrome-stable (in fact, I can't tell how the latter is built
at all). Is that the expected result?

[Jamie, 2014-03-26 21:57:19]

On 2014/03/25 19:36:50, Jamie wrote:
> On 2014/03/24 17:22:58, Paweł Hajdan Jr. wrote:
> > Please see https://code.google.com/p/chromium/issues/detail?id=264789 for
> > instructions about building official packages.
> > 
> > The actual launcher script is
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/installer/l...
> 
> Thanks for the pointer. I've updated the CL to modify that script instead of
the
> two build.sh scripts. When I build linux_packages_stable, and examine the
> resulting .deb file, I see my change in opt/google/chrome/google-chrome, but
not
> in usr/bin/google-chrome-stable (in fact, I can't tell how the latter is built
> at all). Is that the expected result?

Ping

[Paweł Hajdan Jr., 2014-03-28 09:36:05]

LGTM

[Jamie, 2014-03-28 15:45:33]

The CQ bit was checked by jamiewalch@chromium.org

[commit-bot: I haz the power, 2014-03-28 15:47:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamiewalch@chromium.org/190473005/20001

[cmp, 2014-03-30 16:53:16]

The CQ bit was unchecked by cmp@chromium.org

[cmp, 2014-03-30 16:55:26]

The CQ bit was checked by cmp@chromium.org

[commit-bot: I haz the power, 2014-03-30 16:56:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamiewalch@chromium.org/190473005/20001

[commit-bot: I haz the power, 2014-03-30 20:41:01]

Change committed as 260461