New window does not show within Chrome Remote Desktop |
||
Issue descriptionChrome 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.
,
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: ~ $
,
Jun 8 2017
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?
,
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..
,
Jun 8 2017
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.
,
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
,
Jun 12 2017
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.
,
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..
,
Jun 13 2017
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.
,
Jun 13 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by jamiewa...@chromium.org
, Jun 8 2017