Reporting a bug
Browser window closes but browser not shutdown.
The browser instance should be shutdown.
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: https://github.com/DevExpress/testcafe/issues/2194 and/or https://github.com/DevExpress/testcafe/issues/2132
Tested page URL:
Test code
Also experiencing this as well on v.19.1. Curious if there's a fix incoming.
works without issues wit node 8
operating system: MAC OS X 10.13.3
testcafe: 0.19.1,
node.js version: 8.10.0
I'm seeing this as well.
node.js v8.9.4
testcafe 0.19.1
Mac OSX 10.11.6
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:
open -n -a /Applications/Google\ Chrome.app --args http://google.com
psnode module, and type something like:psnode = require('psnode')
psnode.lookup({ arguments: 'google' }, (err, processList) => {global.err = err; global.processList = processList; console.log('done')})
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.
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.
@AndreyBelym Just tried this out to see if it worked and had the following error.
```processList[0] { pid: '2024214751',
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/
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' }
```
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' }
It works if I kill ppid
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 :)
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. :/
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.
Ah, I see. Thanks @AndreyBelym. I'll try a different site.
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
[]
>
@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
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.
Thanks @AndreyBelym. Looked into the ps-node module. It seems like this is the culprit.
https://github.com/neekey/table-parser/issues/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 https://github.com/DevExpress/testcafe/blob/35e5919de499e93b8520f78526dd20960a55b63c/src/browser/provider/utils/kill-browser-process.js#L21
{arguments: browserId, psargs: 'aux'}
@Sushindhran, it's great, I'm testing the fix on Linux!
@AndreyBelym is it working ??
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.
@andreybelym.. Sorry for being desperate... Take care man.. And thanks for the check-in
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!
Hi @gregorycv, please check the [email protected], I've made some improvements to the browser process termination code in this version.
@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!
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.
@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
@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
This is happening for me on macOS Mojave using Chrome 70.
@RichieAHB, could you please try to install [email protected] and check if it fixes the problem?
Is that alpha.2 or is there a release there?
Yes, my mistake, you should try [email protected].
@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.
@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.
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.
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.
Most helpful comment
@Sushindhran, it's great, I'm testing the fix on Linux!