Add wait: false to options object for opn

[evalexpr]

Fixes #3113.

As far as I can see, there is no downside to adding { wait: false } to the option args when invoking opn, if someone can think of one then I'm happy to test that path.

Adding wait : false adds cpOpts.stdio = 'ignore'; and cpOpts.detached = true; to the childProcess.spawn option object. see the relevant opn code

Testing on Ubuntu before the change:

• With no browser open: starting react-scripts/start.js via yarn or npm then terminating the process via <Ctrl>c would also terminate the browser session

After:

• With no browser open: starting react-scripts/start.js via yarn or npm then terminating the process via <Ctrl>c does not terminate the browser session.

This fixes #3113 for me on Ubuntu and causes no regressions on macOS Mojave (where I was unable to replicate the issue due to it not using xdg-open) Didn't get a chance to test on Windows so would be nice if someone else could give that a go.)

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[mrmckeb]

@W1lkins Out of interest, what happens if the browser is already open in Ubuntu (as it is now)? Does it still try to close the browser?

[evalexpr]

@mrmckeb I've recorded some examples where I run a quick script:

#!/bin/bash -e

echo -e "Ubuntu version $(head -n2 /etc/os-release)\\n"
echo -e "Chrome version: $(google-chrome-unstable --version)\\n"
echo -e "Yarn version: $(yarn --version)\\n"
echo -e "Value of options: $(sed -n 99p test-app/node_modules/react-dev-utils/openBrowser.js)\\n"

(I now realise after recording I forgot to check create-react-app --version but it is the latest version: 2.1.8)

Pre-PR behaviour with browser open:

Pre-PR behaviour with browser closed:

Post-PR behaviour with browser open:

Post-PR behaviour with browser closed:

As you can see in the old behaviour (Pre-PR behaviour with browser closed), without wait: false the browser session ends when a SIGINT is sent to the react-scripts/start.js process. However, if the browser instance already exists and CRA isn't responsible for creating the initial session, it doesn't.

Hope this answers your query!

[iansu]

Can we verify that this still works as expected on macOS and Windows? Also, can you rebase this branch with master so we can get the tests passing?

[evalexpr]

I've tested both starting from no browser open and starting with the browser already open on:

MacOS:

• OS: Mojave 10.14
• Yarn: 1.15.2
• CRA: 2.1.8
• Chrome: 74.0.3729.6 dev

Windows:

• OS: 10 Home 64-Bit (10.0, Build 17134)
• Yarn: 1.15.2
• CRA: 2.1.8
• Chrome: 72.0.3626.121

[iansu]

Thanks!