Can Chrome not be restarted on starting, can tab be auto-closed after automation?

[kensoh]

TagUI kills existing Chrome process before starting automation, in order to establish a websocket connection that can only be invoked when a fresh process is started. This makes it inconvenient for users who are having open tabs in Chrome, especially during research and development.

Creating this issue to revisit -

1. Whether it is technically possible to do so now without killing existing process
2. Whether tab can be closed at end of automation to end browser state cleanly

[kensoh]

The rationale for this issue is to check 1. if it is possible now to run TagUI while keeping users' existing tabs open (maybe reading documentation or some other reference materials) and 2. to keep Chrome behavior consistent across different OSes, for eg not having many tabs with batch automation.

[kensoh]

Lines to evaluate whether restarting Chrome is necessary -

https://github.com/kelaberetiv/TagUI/blob/28b5d26f146edd476d6cb8c2ae5fc9fc9af10d89/src/tagui#L291

https://github.com/kelaberetiv/TagUI/blob/28b5d26f146edd476d6cb8c2ae5fc9fc9af10d89/src/tagui.cmd#L565

[kensoh]

Verified that with current Chrome release (v66.0), the behavior remains. If an existing session of Chrome is not killed before initiating Chrome process with websocket opened, there won't be a connection for interacting with and controlling Chrome (see below, nothing returned)

TA:Desktop kensoh$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 about:blank
Created new window in existing browser session.
TA:Desktop kensoh$ curl -s localhost:9222/json
TA:Desktop kensoh$ curl -s localhost:9222

If existing session is killed before launching Chrome, curl -s localhost:9222/json will return results of existing tabs of Chrome for connecting to and controlling the activity in Chrome.

[kensoh]

Found a workaround to force Chrome open as a new process - by explicitly specifying a user directory using --user-data-dir switch, for example tagui/src/chrome/tagui_user_profile folder.

curl -s localhost:9222/json will now return value. Challenge is how to kill this new process after execution without touching the existing process, and let that work for both Linux and Windows.

TA:src kensoh$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=chrome/tagui_user_profile --remote-debugging-port=9222 about:blank

---

Or alternatively, just exit the tab leaving the new Chrome process idling. But security standards prevent browser tab from being able to be closed by script. window.close(); or this.close() or close() returns undefined from Chrome.

Which means have to kill just that new process. Probably using ps and grep command to get the ID to kill. For Windows need to check for what can be used, so behavior is consistent across OSes.

---

For macOS / Linux, following command returns process ID Chrome session launched by TagUI -
ps | grep remote-debugging-port | cut -d' ' -f 1 | sort -nu | head -n 1

For macOS / Linux, following in tagui file will kill the Chrome process launched by TagUI -

chrome_process_id="$(ps | grep remote-debugging-port=9222 | grep tagui_user_profile | cut -d' ' -f 1 | sort -nur | head -n 1)"
if [ -n "$chrome_process_id" ]; then kill $chrome_process_id; fi

[kensoh]

Above commit adds in working version of this new feature, with following implementation -

final version for macOS / Linux, to handle leading space if process id is short

chrome_process_id="$(ps | grep remote-debugging-port=9222 | grep tagui_user_profile | sed -e 's/^[ ]*//' | cut -d' ' -f 1 | sort -nur | head -n 1)"
if [ -n "$chrome_process_id" ]; then kill $chrome_process_id; fi

---

final version for Window using wmic command to retrieve process id

for /f "tokens=* usebackq" %%p in (`wmic process where "caption like '%%chrome.exe%%' and commandline like '%%tagui_user_profile --remote-debugging-port=9222%%'" get processid 2^>nul ^| cut -d" " -f 1 ^| sort -nur ^| head -n 1`) do set chrome_process_id=%%p
if not "!chrome_process_id!"=="" taskkill /PID !chrome_process_id! /T /F > nul 2>&1

---

Above blocks of code to kill the Chrome processes launched by TagUI will be executed before running automation and then after running automation as per the original workflow. If speed mode is use, the process will not be killed.

In addition, for batch automation, the behavior would be restarting with the single new tab.

[kensoh]

This feature is now usable from cutting edge version which can be downloaded here to overwrite existing local packaged installation. (backup beforehand).

How it works is by creating a separate Chrome user profile for TagUI's use, so that profile is launched whenever TagUI automation is run. This way, existing Chrome browser tabs used by the user will not be closed and affect their work.

Credentials (signed-in passwords and so on), will have to be re-entered as the browser will start off on a clean slate during the first run. Eg can use wait 30 seconds or live step to pause the automation to login. @adegard might find this useful.

[shoeper]

This way, existing Chrome browser tabs used by the user will not be closed and affect their work.

The interesting thing is that on my linux machine (Fedora 28) even with the last release my running chrome hasn't been closed.

[kensoh]

Oh my colleague has this observation as well, his Linux Chrome doesn't get killed on running TagUI automation. Looks like it is only impacting Windows and macOS. I wonder why. In the last version, there is a pkill google-chrome command at start and end of execution, not sure why that process it not killed.

Perhaps the existing chrome proesss is not called google-chrome command, or that process is launched under a different user from the shell invoking TagUI?

[kensoh]

I've informed power users about this new feature.. See if there are bugs or improvements to be made from the commit. Frankly, the way to get process id using ps / wmic and doing string manipulation using cut, sort, head etc is not ideal but what I found to be compatible with existing architecture of invoking from shell / batch script, that works regardless whether users have a development environment or not.

[shoeper]

process is launched under a different user from the shell invoking TagUI

This is not the case.

Having a look at the command above ps | grep remote-debugging-port=9222 | grep tagui_user_profile I think the ps is the issue. On linux it needs to be at least ps a, I'd run ps ax or ps aux.

By default, ps selects all processes with the same effective user ID (euid=EUID) as
the current user and associated with the same terminal as the invoker. It displays
the process ID (pid=PID), the terminal associated with the process (tname=TTY), the
cumulated CPU time in [DD-]hh:mm:ss format (time=TIME), and the executable name
(ucmd=CMD). Output is unsorted by default. - man ps

[kensoh]

I see, you are saying that the process is called as the same user but not picked up by the ps command on Linux. @lohvht we can have a look at your Linux's environment this week to see why the last version of TagUI doesn't kill existing user browser tabs (that behavior will be be ok not to be changed), but at least the cutting version should kill the session invoked as tagui_user_profile.