element icon indicating copy to clipboard operation
element copied to clipboard

Running with multiple users (--mu) setting locally opens incorrect browser and ignores all test settings

Open Danbown opened this issue 3 years ago • 0 comments

Describe the bug I have a test script that requires Chrome browser, a proxy server (with address, username, password), and executable path for Chrome. When I run a single script locally, all is fine - Chrome opens as expected and uses correct proxy. When I use --mu parameter to run with concurrent users, script generates: a) wrong browser is opened (Chromium rather than Chrome) b) proxy settings are not picked up at script level, meaning that all instances fail authentication

To Reproduce Steps to reproduce the behavior:

I have set 'stages' and selected settings as below: browser: 'chrome', stages: [ { duration: '1m', target: 3 }], browserLaunchOptions: { executablePath: '/Program Files (x86)/Google/Chrome/Application/chrome.exe', proxy: { server:'http://myserver', username: 'myusername', password: 'mypassword', bypass:'.mybypassdomain', } }, I then run the .ts file with --no-headless --export --mu from the command line.

Expected behavior Multiple instances of Chrome will open and navigate successfully to site and return confirmation of page content

Screenshots Not applicable but messages returned read: 'This kind of browser does not support CDPSession'

Desktop (please complete the following information):

  • OS: Windows 10, running on VM
  • Node.js version: 14.17.2
  • Version element: 2.0.4

Additional context

error messages seen when checking for update version:

Error! Checking for updates failed TypeError: Cannot read property 'code' of undefined at getMostRecent (C:\Users\dbown\AppData\Roaming\npm\node_modules\element-cli\node_modules\update-check\index.js:125:11) at async Object.module.exports [as default] (C:\Users\dbown\AppData\Roaming\npm\node_modules\element-cli\node_modules\update-check\index.js:185:12) 2.0.4

I would also add that I observe two more issues: a) setting 'incognito: false,' does not alter browser behaviour. Chrome is always incognito whether this is true or false. b) using --export parameter does not generate a report - I will raise a separate bug for this

Thanks, Dan

Danbown avatar Jul 08 '21 23:07 Danbown