New issue
Advanced search Search tips

Issue 730867 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

New window does not show within Chrome Remote Desktop

Project Member Reported by porce@chromium.org, Jun 7 2017

Issue description

Chrome Version: 
$ google-chrome --product-version
59.0.3071.86
Server OS: Goobuntu, Client OS: macOS 10.12

What steps will reproduce the problem?
(1) Log on to the Goobuntu console. Within the window manager, enable remote desktop. Open a Chrome browser
(2) At a client, access that Goobuntu using Chrome Remote desktop.
(3) Within the Chrome Remote desktop, click Chrome browser icon to start a window.

What is the expected result?
A new Chrome window pops up in Chrome Remote desktop

What happens instead?
No new window pops up. Instead, the window pops up in the Goobuntu's console.
Since the Remote Desktop does not show the Goobuntu's console, I could not use the Chrome Browser at all via Remote Desktop.


Please provide a work-around if any.

 
Labels: -OS-Mac
Can you check that the CHROME_USER_DATA_DIR environment variable is set on the remote desktop? It's supposed to cause Chrome to use a dedicated profile directory for CRD, but there was a change made to that logic recently which might have broken it.

Comment 2 by porce@chromium.org, Jun 8 2017


porce@porce-ws: ~
$ hostname
porce-ws.svl.corp.google.com

porce@porce-ws: ~
$ echo $CHROME_USER_DATA_DIR


porce@porce-ws: ~
$ google-chrome --product-version
59.0.3071.86

porce@porce-ws: ~
$
Did you check this from inside the CRD session? If so, then that explains the problem--CHROME_USER_DATA_DIR should be set, but it isn't. Do you have a custom ~/.chrome_remote_desktop_session file?

Comment 4 by porce@chromium.org, Jun 8 2017

#2 was from ssh session into the Goobuntu box. 

This is from a terminal within a CRD session to that Goobuntu box.
porce@porce-ws: ~
$ echo $CHROME_USER_DATA_DIR
/usr/local/google/home/porce/.config/chrome-remote-desktop/chrome-profile

porce@porce-ws: ~
$ ls -l ~/.chrome_remote_desktop_session
ls: cannot access /usr/local/google/home/porce/.chrome_remote_desktop_session: No such file or directory

I have tar.gzed that directory, which leads to 64MB. As long as it does not have PII, I can share with you for debugging purpose..


If there's no chrome_remote_desktop_session file, then the contents won't be useful (and will certainly contain PII) so there's no need to send it.

In the window that pops up on the console, can you navigate to chrome://version and tell me what the profile path is set to? It should be the same as the CHROME_USER_DATA_DIR variable. If it is, then that variable has somehow gotten set on the console; unset it and quit Chrome and all will be well. If it isn't, then we have a regression.

Comment 6 by porce@chromium.org, Jun 12 2017

I see difference - hence regression.


Google Chrome	58.0.3029.110 (Official Build) (64-bit)
Revision	691bdb490962d4e6ae7f25c6ab1fdd0faaf19cd0-refs/branch-heads/3029@{#830}
OS	Linux
JavaScript	V8 5.8.283.38
Flash	25.0.0.171 /usr/local/google/home/porce/.config/chrome-remote-desktop/chrome-profile/PepperFlash/25.0.0.171/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Command Line	/opt/google/chrome/google-chrome --user-data-dir=/usr/local/google/home/porce/.config/chrome-remote-desktop/chrome-profile --profile-directory=Default --app-id=gbchcmhmhahfdphkhkmpfmihenigjmpp --flag-switches-begin --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome
Profile Path	/usr/local/google/home/porce/.config/chrome-remote-desktop/chrome-profile/Default
Variations	241fff6c-ca7d8d80
3095aa95-3f4a17df
7c1bc906-f55a7974
ba3f87da-b4a760c3
cf558fa6-48a16532
f3499283-7711d854
349d561b-65bced95
9e201a2b-65bced95
6eb432aa-ca7d8d80
5274eb09-3f4a17df
b684f56f-4d2fac87
b791c1b8-ca7d8d80
9773d3bd-ca7d8d80
b22b3d54-4e046809
2e109477-ca7d8d80
99144bc3-3cc2175e
9e5c75f1-ee841e81
f79cb77b-3f4a17df
b7786474-d93a0620
9591f600-d93a0620
23a898eb-ca7d8d80
4ea303a6-ecbb250e
69bf80fa-91c810ef
b2f0086-93053e47
f11cb941-11910166
494d8760-3d47f4f4
3ac60855-3ec2a267
f296190c-92a7f5c9
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-6e3b1976
e7e71889-e1cc0f14
828a5926-ca7d8d80


Assuming that's the output from the window that opened on the console, the profile path is set to what I would expect it to be inside the Chromoting session (I forgot about the appended /Default when I asked you if they match). What this means is that you've somehow managed to open a Chrome window on your console session pointing to your Chromoting profile, which is generally only used in your Chromoting session.

The easiest fix is just to close all Chrome windows on your console session; next time you run Chrome inside Chromoting, it should open a new window as usual.

Comment 8 by porce@chromium.org, Jun 13 2017

So this is what I have done and noticed.

I closed the all Chromes in Goobuntu and in MacOS client. I started the Chrome Remote Desktop, and the symptom continues.

What is interesting is whenever a Chrome browser windows open via Chrome Remote Desktop, the Chrome version there is 58, while, my Goobuntu's everyday use version is 59.

In suspect, even I downloaded the M60 beta, and from my main console I use M60beta, but still M58 pops up AT the console whenever via the Remote Desktop.

In an another attempt, I used Ubuntu software manger, uninstall and install the Chrome Remote Desktop, and I uninstall and reinstall the Remote Desktop extension from my MacOS Chrome. The issue remains the same.


For now I am exploring NoMachine / VNC.. 
I think you've somehow got another instance of Chrome running on the console of your Goobuntu machine that has its profile directory set to /usr/local/google/home/porce/.config/chrome-remote-desktop/chrome-profile/Default. It's possible that it's running in the background, but I don't know what you might have done to set that up. You could also try to find any instances running using "ps" and kill them.
Status: WontFix (was: Untriaged)

Sign in to add a comment