Tried testing the issue on chrome reported version# 71.0.3578.98 using Windows-10 with steps mentioned below:
1) Launched chrome reported version, placed two files(provided in comment# 0) in same folder
2) Opened terminal, navigated to the folder created in above step
3) Ran the command "mocha -t 10000 test.js" in Command Prompt, seen: 
'mocha' is not recognized as an internal or external command,
operable program or batch file.

@Reporter: Please find above mentioned information and attached screencast for your reference and let us know if we missed anything in reproducing the issue, Provide your feedback. If possible provide screencast of the issue which help in better understanding and further triaging it in better way.

Thanks!

Deleted: 915632.mp4 2.1 MB

	915632.mp4 2.1 MB View Download

Sorry about my inaccurate steps. Hope you're able to reproduce the problem as follows:

1) Install Chrome
2) Install Node.js
3) Download the latest ChromeDriver (https://chromedriver.storage.googleapis.com/index.html?path=2.45/)
4) Extract chromedriver.exe to C:\webdrivers
5) Download updated package.json and test.js to C:\webdrivers
6) Open Command Prompt and run the following commands:
>set PATH=%PATH%;C:\webdrivers
>npm install -g mocha
>cd C:\webdrivers
>npm install
7) Run test in visible mode and it passes (note Root 1 and Root 2 being visible)
>set CHROME_TEST_MODE=visible
>mocha -t 10000 test.js
8) Run test in headless mode and it fails
>set CHROME_TEST_MODE=headless
>mocha -t 10000 test.js
9) Open C:\webdrivers\screenshot.png to see that "Basic AJAX demo" is still in a loading state when failing in headless mode.

Chrome is behaving differently depending on mode. Any thoughts? Thanks!

Deleted: package.json 65 bytes

package.json 65 bytes View Download

Deleted: test.js 1.3 KB

test.js 1.3 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on reported version 71.0.3578.98 and the same is not seen on latest canary# 73.0.3644.0 and Beta# 72.0.3626.17 using Windows 10, hence providing reverse bisect info
Note: Unable to test this issue on Ubuntu 14.04 & Mac 10.12.6

Reverse Bisect Info:
================
Last Bad build: 72.0.3582.0
First Good build: 72.0.3583.0

Note: On running Per-revision bisect getting error, on chromium builds unable to reproduce the issue, hence providing below change-log from omahaproxy
Change-Log: https://chromium.googlesource.com/chromium/src/+log/72.0.3582.0..72.0.3583.0?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/d5f73ba89a508cc9c9e40aa279f68eca82e4f1ce from above change-log
Change-Id: I1d053de59f0e6c07cfe42b29a3e09aaab91ac330
Reviewed-on: https://chromium-review.googlesource.com/c/1281166

Note: As the author(Johannes Henkel) last visit is more than 29 days, hence assigning it to reviewer(Dmitry Gozman)
@Dmitry Gozman: Please confirm the issue and help in re-assigning if it is not related to change, please help in merging it to M-71 if applicable
Adding ReleaseBlock-Stable for M-71, feel free to remove it if not applicable.

Thanks!

Doesn't look like a stable blocker, given that M72 is fine anyway. Andrey, mind double checking whether this is fixed?