Seems it is out of scope from TE end as it is related to evToolsActivePort file , adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Thanks..!

We don't need any help from TE for this.

The bug is that the cast_shell version of Chromium does not support --remote-debugging-port=0 flag. This code https://cs.chromium.org/chromium/src/chromecast/browser/devtools/remote_debugging_server.cc?q=%22Devtools+started:+port%3D%22&sq=package:chromium&g=0&l=188

passes an empty filepath for "active_port_output_directory" to StartRemoteDebuggingServer. With an empty filepath, StartRemoteDebuggingServer decides not to write the port number that it chooses to anywhere.

Since this is open source code, I am removing the Restrict-View-Google label. You can add it back if there is any confidential information in this bug (but I doubt there will be).

+John FYI.

cast_shell doesn't have a user-data-dir, so plan is to place the file in $DIR_CAST_HOME/DevToolsActivePort and make a symlink from where chromedriver expects the file to $DIR_CAST_HOME/DevToolsActivePort

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2f57a9618a8514b043d5c237bf7bae3a32023d74

commit 2f57a9618a8514b043d5c237bf7bae3a32023d74
Author: Caleb Rouleau <crouleau@chromium.org>
Date: Tue Jun 26 20:55:10 2018

[Cast Shell] Write DevTools port file to DIR_CAST_HOME.

When you send --remote-debugging-port=0 to Chrome, devtools chooses
its own port and writes it to chrome::DIR_USER_DATA as a file
named "DevToolsActivePort". Cast doesn't have a user data dir,
so this CL writes the file to chromecast::DIR_CAST_HOME.

The ability to specify a 0 as the port is needed to avoid the
race condition of some other process binding to a port that you
choose before Chrome gets a chance to bind to it. ChromeDriver
switched to using DevToolsActivePort to fix a race condition:
https://bugs.chromium.org/p/chromedriver/issues/detail?id=2161

ChromeDriver does not natively work with cast_shell, but you
can pass a shell script as the chrome binary to ChromeDriver
and then have the shell script write a symbolic link from
DevToolsActivePort in the user-data-dir flag value that
ChromeDriver provides to the DIR_CAST_HOME directory.

Therefore, this change allows cast_shell to work with
ChromeDriver again.

Note that the "Devtools started: port=X" log is not needed
since DevTools code logs something like
"DevTools listening on
ws://0.0.0.0:45447/devtools/browser/665edec7-dbee-4547-816e-1d5e0c4a5dd3"

already.

Bug:  854864 ,  chromedriver:2161 
Change-Id: I55c20881607d581f628840cdf906569807f541ca
Reviewed-on: https://chromium-review.googlesource.com/1114378
Commit-Queue: Caleb Rouleau <crouleau@chromium.org>
Reviewed-by: Stephen Lanham <slan@chromium.org>
Reviewed-by: John Chen <johnchen@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570526}
[modify] https://crrev.com/2f57a9618a8514b043d5c237bf7bae3a32023d74/chromecast/browser/devtools/remote_debugging_server.cc