Comments (8)
Ah, yea, for ChromeDriver < 115 it'd need to download from the old URL. See https://chromedriver.chromium.org/downloads.
from webdriverio.
I'm not sure how using the Chromedriver service helps here?
The Chromedriver service would allow to download a Chromedriver version before v115 of Chrome. You could use it within the onPrepare
hook to download Chromedriver if the Electron version is v25 or lower.
I will simply update the Electron service docs to specify that Electron versions lower than 26 will require manual configuration of Chromedriver.
I think this would be the best since there aren't many Electron v25 devs out there anymore.
from webdriverio.
Thanks @goosewobbler 👍
from webdriverio.
I'm not sure how using the Chromedriver service helps here?
The Chromedriver service would allow to download a Chromedriver version before v115 of Chrome. You could use it within the
onPrepare
hook to download Chromedriver if the Electron version is v25 or lower.
FWIW: Here's an over-complicated example. I set up the onPrepare
hook to download ChromeDriver for Linux ARM64 from the Electron releases on GitHub instead of from ChromeDriver or Chrome for Testing. It does a bit extra since it's for the VS Code service. 🤷
https://github.com/seanpoulter/wdio-vscode-cucumber-example/blob/main/test/wdio.conf.ts#L199-L301
from webdriverio.
We have introduced Chrome for Testing to manage Chrome and Chromedriver downloads. Chrome for Testing starts with Chrome 115 and up, therefor it is not possible to use a lower version number, except using the Chromedriver service which you can still do.
Could you give the wdio-chromedriver-service
a shot and see it manages the driver for you?
from webdriverio.
Apologies, I think I misunderstood something regarding Chrome for Testing and conflated their CD support level with Electron's rolling support. So the lowest CD version available on CfT is fixed at 115, which corresponds to Electron 26. This is less of an issue as before long, most Electron users will be off v25 and lower.
If with this we are saying that given the pace of Chromedriver / Electron releases, adding a download fallback for Chromedriver < 115 to WDIO is not worth it, I will simply update the Electron service docs to specify that Electron versions lower than 26 will require manual configuration of Chromedriver.
I'm not sure how using the Chromedriver service helps here?
from webdriverio.
Thanks for the clarification, I'll close this then - Electron service docs update here.
from webdriverio.
Thanks for the example, there was something similar in the Electron service before WDIO started handling CD downloads, we were using @electron/get
though: https://github.com/webdriverio-community/wdio-electron-service/blob/4.3.0/src/launcher.ts
from webdriverio.
Related Issues (20)
- [🐛 Bug]: Tests not running on grid after upgrading to wdio v9 HOT 2
- [🐛 Bug]: Some elements not detected by the new shadow element detection HOT 1
- [💡 Feature]: Add option to add console logs to junit report HOT 3
- [🐛 Bug]: Fix customElement wrapper for custom elements which don't define connectedCallback or disconnectedCallback
- [🐛 Bug]: XPath locators work differently since v9 HOT 2
- [🐛 Bug]: @wdio/appium-service: [AppiumDriver@3989] Error: WebSocket is not open: readyState 0 (CONNECTING) HOT 5
- [🐛 Bug]: v9 browser.mock take a lot of time if url length is above 25 HOT 10
- [🐛 Bug]: wdio@8 brings nested dependency pointing to wdio@9 HOT 1
- [🐛 Bug]: wdio-cli specify Options.Testrunner type in typescript mode instead of WebdriverIO.Config
- [🐛 Bug]: v9: TypeError: fetch failed (ECONNREFUSED) HOT 10
- [🐛 Bug]: Incorrect file type in specs when using cucumber framework HOT 2
- [🐛 Bug]: v9 browser.mock not returning mock response HOT 6
- [🐛 Bug]: [v9 ][CRITICAL] Misfound elements when BiDi locators lose parent context and fall back to WebDriver Classic HOT 9
- [🐛 Bug]: v9 has issues with waitForDisplayed if the page changes HOT 7
- [🐛 Bug]: All tests are run in all workers HOT 4
- [🐛 Bug]: cucumber.js path overrides wdio.conf.js exclude HOT 2
- [🐛 Bug]: v9: junit-reporter: Report is empty HOT 6
- [🐛 Bug]: Alert closes immediately after calling `window.alert()` HOT 2
- [🐛 Bug]: context.skip() behaviour is inconsistent with Sync and Async mocha hooks HOT 2
- [🐛 Bug]: 'capabilities' does not exist in type 'Testrunner' HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webdriverio.