Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Browser instance not shutdown (but tab/window closes) #2226

Closed
nmackey opened this issue Mar 18, 2018 · 33 comments
Closed

Browser instance not shutdown (but tab/window closes) #2226

nmackey opened this issue Mar 18, 2018 · 33 comments
Assignees
Labels
OS: Mac STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: browser natives TYPE: bug The described behavior is considered as wrong (bug).

Comments

@nmackey
Copy link

nmackey commented Mar 18, 2018

Are you requesting a feature or reporting a bug?

Reporting a bug

What is the current behavior?

Browser window closes but browser not shutdown.

What is the expected behavior?

The browser instance should be shutdown.

How would you reproduce the current behavior (if this is a bug)?

Run any test suite (tried with multiple projects) with Chrome, Headless Chrome, Safari, Firefox (Headless Firefox seems to work)
With Chrome I did try moving back versions of testcafe to isolate when the bug was introduced and it seems to have been introduced between 0.17.2 and 0.18.0
This could be related to: #2194 and/or #2132

Provide the test code and the tested page URL (if applicable)

Tested page URL:

Test code

Specify your

  • operating system: MAC OS X 10.13.3
  • testcafe version: 19.1
  • node.js version: 9.2.0
nmackey pushed a commit to nmackey/react-router-navigation-prompt that referenced this issue Mar 19, 2018
`-k` kills concurrently when the tests complete
Had to revert to testcafe version 0.17.2 to have chrome close on completion.  Filed a bug with testcafe - DevExpress/testcafe#2226
@AlexanderMoskovkin AlexanderMoskovkin added TYPE: bug The described behavior is considered as wrong (bug). OS: Mac SYSTEM: browser natives labels Mar 19, 2018
@graeme-plangrid
Copy link

Also experiencing this as well on v.19.1. Curious if there's a fix incoming.

@Hotell
Copy link

Hotell commented Mar 23, 2018

works without issues wit node 8

operating system: MAC OS X 10.13.3
testcafe: 0.19.1,
node.js version: 8.10.0

@Sushindhran
Copy link

I'm seeing this as well.

node.js v8.9.4
testcafe 0.19.1
Mac OSX 10.11.6

@AndreyBelym
Copy link
Contributor

AndreyBelym commented Apr 2, 2018

Hi @nmackey @graeme-plangrid @Sushindhran!

Unfortunately, I can't reproduce issue on Macs here. I need time to make a debug build. Meanwhile, if you have some free time, you can check how the lookup and kill functions from the ps-node module works on your machine. When closing a browser, TestCafe tries to find a browser process by using lookup with a piece of a command line parameter passed when browser was opened, and then uses kill to terminate the process. So you have to:

  1. Start the browser with a command line parameter
open -n -a /Applications/Google\ Chrome.app --args http://google.com
  1. Open Node.js REPL in a directory with the installed psnode module, and type something like:
psnode = require('psnode')
psnode.lookup({ arguments: 'google' }, (err, processList) => {global.err = err; global.processList = processList; console.log('done')})
  1. Wait until 'done' will be printed to console, and then type err and processList in CLI. If you have have ReferenceError: err is not defined and some list printed in console, it's fine, try the last step. Otherwise share you can share the err output here and in the psnode issues.

  2. Try to execute

processList[0]
psnode.kill(processList[0].pid, (err) => console.log(err || 'done'))

If all is OK, you will have an object dump and the word 'done' printed in you console (with some delay). If it displays some error, share the object dump and the error here.

@frankmariette
Copy link

frankmariette commented Apr 2, 2018

@AndreyBelym Just tried this out to see if it worked and had the following error.

  command: '??',
  arguments:
   [ '0:04.67',
     '/Applications/Google',
     'Chrome.app/Contents/Versions/65.0.3325.181/Google',
     'Chrome',
     'Helper.app/Contents/MacOS/Google',
     'Chrome',
     'Helper',
     '--type=renderer',
     '--field-trial-handle=4432648620277866634,9616517174019563587,131072',
     '--service-pipe-token=64441D545C038F2F92E87ED15CC3920F',
     '--lang=en-US',
     '--enable-offline-auto-reload',
     '--enable-offline-auto-reload-visible-only',
     '--num-raster-threads=4',
     '--enable-zero-copy',
     '--enable-gpu-memory-buffer-compositor-resources',
     '--enable-main-frame-before-activation',
     '--enable-compositor-image-animations',
     '--service-request-channel-token=64441D545C038F2F92E87ED15CC3920F',
     '--renderer-client-id=317' ],
  ppid: '353' }

psnode.kill(processList[0].pid, (err) => console.log(err || 'done'))
{ Error: kill ESRCH
    at Object._errnoException (util.js:1024:11)
    at process.kill (internal/process.js:183:18)
    at Function.exports.kill (/Users/frankmariette/Projects/<Project-name>/node_modules/ps-node/lib/index.js:211:13)
    at repl:1:8
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)
    at REPLServer.defaultEval (repl.js:240:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:442:10)
    at emitOne (events.js:121:20) code: 'ESRCH', errno: 'ESRCH', syscall: 'kill' }

@Sushindhran
Copy link

I'm seeing the same thing.

{ pid: '1427822843',
  command: '??',
  arguments:
   [ '0:02.53',
     '/Applications/Google',
     'Chrome.app/Contents/MacOS/Google',
     'Chrome',
     'http://google.com' ],
  ppid: '8768' }
{ Error: kill ESRCH
    at Object._errnoException (util.js:1022:11)
    at process.kill (internal/process.js:183:18)
    at Function.exports.kill (/Users/sushindhran/Projects/test/node_modules/ps-node/lib/index.js:211:13)
    at repl:1:8
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)
    at REPLServer.defaultEval (repl.js:240:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:468:10)
    at emitOne (events.js:121:20) code: 'ESRCH', errno: 'ESRCH', syscall: 'kill' }

@Sushindhran
Copy link

It works if I kill ppid

@frankmariette
Copy link

Trying out your solution @Sushindhran I get the same result with using ppid. Trying to fork testcafe to make the fix however doesn't work for me as the test scripts seem to require them to be ran on a Windows 10 machine which I do not have access to. Maybe one of the people from testcafe can make this fix and hopefully update their contribution docs to allow mac users to make contributions as well :)

@Sushindhran
Copy link

Sushindhran commented Apr 3, 2018

Seems like the issue is that psnode.lookup doesn't find the right pid. The pid I see in processList[0] doesn't exist. I haven't had the time to delve deeper into this and debug. I also don't have access to a windows machine for now. :/

@AndreyBelym
Copy link
Contributor

AndreyBelym commented Apr 3, 2018

Hi @frankmariette @Sushindhran, I didn't expect that the app path (/Applications/Google Chrome/bla-bla-bla) goes to the arguments on macOS. Could you please try to use different URL (like http://example.com, http://bing.com, etc.) and accordingly run psnode.lookup({ arguments: 'example' }, ... or psnode.lookup({ arguments: 'bing' }, ... in the 2nd step?

ppid means Parent Process ID. You have captured info for a Chrome render process, that can be started and finished by browser time-to-time, and when you kill it's parent you kill the main process of the browser. It happened because google was specified as a keyword for search in arguments of process, and it matched to the Chrome app path. It can't happen with TestCafe, because TestCafe passes a special generated identifier in the browser arguments, which is quite guaranteed to be unique.

@Sushindhran
Copy link

Ah, I see. Thanks @AndreyBelym. I'll try a different site.

@frankmariette
Copy link

Hey @AndreyBelym I tried out using a different URL though lookup is unable to find anything so processList comes back empty. Here is the console output for the different URL.

$: open -n -a /Applications/Google\ Chrome.app --args http://www.yahoo.com
$: node
> psnode = require('ps-node')
{ [Function: exports] lookup: [Function], kill: [Function] }
> psnode.lookup({ arguments: 'yahoo' }, (err, processList) => {global.err = err; global.processList = processList; console.log('done')})
undefined
> done
> processList
[]
>

@Sushindhran
Copy link

Sushindhran commented Apr 3, 2018

@AndreyBelym - Tried the same with github.com

psnode.lookup({ arguments: 'github' }, (err, processList) => {global.err = err; global.processList = processList; console.log('done')})
undefined
> done
> processList
[ { pid: '1427822843',
    command: '??',
    arguments:
     [ '0:03.40',
       '/Applications/Google',
       'Chrome.app/Contents/MacOS/Google',
       'Chrome',
       'http://github.com' ],
    ppid: '37716' } ]
> processList[0]
{ pid: '1427822843',
  command: '??',
  arguments:
   [ '0:03.40',
     '/Applications/Google',
     'Chrome.app/Contents/MacOS/Google',
     'Chrome',
     'http://github.com' ],
  ppid: '37716' }
> psnode.kill(processList[0].pid, (err) => console.log(err || 'done'))
{ Error: kill ESRCH
    at Object._errnoException (util.js:1022:11)
    at process.kill (internal/process.js:183:18)
    at Function.exports.kill (/Users/sushindhran/Projects/test/node_modules/ps-node/lib/index.js:211:13)
    at repl:1:8
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)
    at REPLServer.defaultEval (repl.js:240:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:468:10)
    at emitOne (events.js:121:20) code: 'ESRCH', errno: 'ESRCH', syscall: 'kill' }

Edit:

Did a ps aux | grep github and I'm seeing this

 sushindhran 37716   0.0  1.3  3144004 212456   ??  S    12:06PM   0:03.94 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome http://github.com

@AndreyBelym
Copy link
Contributor

Thank you kindly @Sushindhran! Looks like ps-node incorrectly parses output of ps in your case. Some of us should submit a bug report to the ps-node 😈. I will submit the bug and post a link to an issue here, If I reproduce the problem, or figure out what causes it.

@Sushindhran
Copy link

Sushindhran commented Apr 3, 2018

Thanks @AndreyBelym. Looked into the ps-node module. It seems like this is the culprit.

neekey/table-parser#11

Edit:

Looks like ps-node runs ps lx by default. This bug would be fixed if we run ps aux when testcafe calls psnode.lookup. Is this a viable solution @AndreyBelym ?

Essentially replacing this line

var processOptions = { arguments: browserId };

{arguments: browserId, psargs: 'aux'}

@AndreyBelym
Copy link
Contributor

@Sushindhran, it's great, I'm testing the fix on Linux!

@vigneshwar-v
Copy link

vigneshwar-v commented Apr 6, 2018

@AndreyBelym is it working ??

@AndreyBelym
Copy link
Contributor

Hi @vigneshwar-v. it works. I've caught a cold, so the fix was delayed a bit, but I will try to ship it ASAP now.

@vigneshwar-v
Copy link

@AndreyBelym.. Sorry for being desperate... Take care man.. And thanks for the check-in

@gregorycv
Copy link

gregorycv commented Sep 6, 2018

Hi, @Sushindhran 's solution has worked for chrome but while testing in safari and firefox there are still some issues.

Safari closes the tab, but not the browser and, in addition to that, the node process keeps running and I need to quit it with ctrl+c.

Firefox closes the browser, but the same thing with the node process occurs.

Any suggestions how to go about this?
@AndreyBelym
Huge thanks!

@AndreyBelym
Copy link
Contributor

Hi @gregorycv, please check the [email protected], I've made some improvements to the browser process termination code in this version.

@gregorycv
Copy link

gregorycv commented Sep 6, 2018

@AndreyBelym thanks for your prompt reply.
Excuse me if I am getting something wrong as I am still fairly new to GitHub and TestCafe

I am currently using TestCafe 0.22 on MacOS with Chrome 68.0.3440, Safari 11.1.1 and Firefox 61

Once TestCafe is installed and
var processOptions = { arguments: browserId, psargs: '-ef' }; in testcafe/src/browser/provider/utils/kill-browser-process.js
neither of the browsers close correctly after test execution

If I change that to
{arguments: browserId, psargs: 'aux'}
both Chrome and Firefox are closed after all tests have completed execution, but not Safari.

On top of that - in case with Firefox and Safari node process does not terminate.

Please let me know if that's an issue on my side or a more general problem.

I'd gladly share any additional information if that helps.

Thanks!

@AndreyBelym
Copy link
Contributor

AndreyBelym commented Sep 6, 2018

The psargs: 'aux' options was used in [email protected], could you please check that it works on your machine? I've changed the psargs value to -ef because some users still reported the problem with the aux parameter, but not with the -ef parameter.

I've never reproduced the problem with hanging node process on macOS, so I will think about how to collect debug information for your case.

TestCafe can't terminate Safari process in general, because all Safari windows and tabs in the system share the same process. It means that if TestCafe terminate the process, TestCafe will close also windows and tabs opened by a user, it would be too frustrating. Maybe it's possible to check if TestCafe's window is the only Safari window opened, and close it in this case.

@gregorycv
Copy link

@AndreyBelym
Ok, so I've tried installing 0.21.0 and running my tests, as a result:
chrome works fine both browser and node process are closed and terminated
firefox browser is closed but the process is hanged
safari browser remains open (as you've explained) and the process is hanged

@bhreinb
Copy link

bhreinb commented Sep 11, 2018

@AndreyBelym
I'm seeing exactly the same that @gregorycv described above with same version. Re firefox that occurs for me when I run it headless or in regular mode.

Should this ticket be re-opened?

Btw I also see as part of that test run which may be of concern

(node:2091) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit

@RichieAHB
Copy link

This is happening for me on macOS Mojave using Chrome 70.

@AndreyBelym
Copy link
Contributor

@RichieAHB, could you please try to install [email protected] and check if it fixes the problem?

@RichieAHB
Copy link

Is that alpha.2 or is there a release there?

@AndreyBelym
Copy link
Contributor

Yes, my mistake, you should try [email protected].

@RichieAHB
Copy link

@AndreyBelym works like a charm 👌 - also, while I'm here, I've no idea how you got your drag and dropping working in chrome. Puppeteer and Selenium both failed on this count. Great work.

@RichieAHB
Copy link

@AndreyBelym - we're not that keen on requiring alpha versions on our team, so do you know (very roughly) when this might land? Thanks again.

@AndreyBelym
Copy link
Contributor

AndreyBelym commented Oct 31, 2018

The current estimate for the [email protected] stable release is the middle of November. I'll post a message here as soon as it is released.

@lock
Copy link

lock bot commented Mar 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or feature requests. For TestCafe API, usage and configuration inquiries, we recommend asking them on StackOverflow.

@lock lock bot added the STATE: Auto-locked An issue has been automatically locked by the Lock bot. label Mar 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 28, 2019
kirovboris pushed a commit to kirovboris/testcafe-phoenix that referenced this issue Dec 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
OS: Mac STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: browser natives TYPE: bug The described behavior is considered as wrong (bug).
Projects
None yet
Development

No branches or pull requests