chromium-dashboard
chromium-dashboard copied to clipboard
WebDriver shipping process complex and unclear
Describe the bug There was an announcement that webdriver changes require I2S, but the documentation on how to fill in chromestatus fields for webdriver changes is lacking, or maybe I missed it. The only possibly relevant text seems to be a thread where the proposal was surfaced, but this is not discoverable and needs to be vetted for correctness at the very least. Can we make chromestatus for webdriver easier?
There are a lot of fields where it is either unclear or not applicable what to do for webdriver changes:
- Launch URL: I don't think this is needed?
- Interoperability and Compatibility Risks: unclear how this should be filled in given these changes are not web exposed.
- Safari / Firefox views: unclear to me if the cost of filing these (for both Chrome and other browser vendors) is worth it for these not-web-exposed changes?
- Security / privacy reviews: not needed?
- Ergonomics / Activation / Security Risks: I think all of these are not applicable?
- Debuggability: probably not?
- Web Platform Tests: are there shared browser tests for these?
- TAG review / TAG Specification Review Status: not applicable?
- Origin Trial: this section should be removed altogether / not applicable?
- WebView application risks: not applicable?
- Adoption expectation / Adoption plan / Measurement: all of these seem to be about web-exposed features?
I agree with you that some of the ChromeStatus fields are not always relevant for every change. This includes, but is not limited to, WebDriver changes.
WebDriver changes are newly included in the launch process, and there is agreement that we should figure out the specifics on a case-by-case basis.
Some replies inline, however:
Interoperability and Compatibility Risks: unclear how this should be filled in given these changes are not web exposed.
The thread addresses this:
Changes to WebDriver are developer-exposed (but not web-exposed). Developers either rely on these commands/events directly in their automation scripts, or use abstractions like Puppeteer/Selenium that rely on them. Thus, similar compatibility and interoperability concerns apply as for Web-exposed features.
Web Platform Tests: are there shared browser tests for these?
Absolutely. See https://wpt.fyi/results/webdriver/tests/classic for WebDriver Classic and https://wpt.fyi/results/webdriver/tests/bidi for WebDriver BiDi.
I agree with you that some of the ChromeStatus fields are not always relevant for every change. This includes, but is not limited to, WebDriver changes.
Not limited to WebDriver, but especially so since they are not web exposed changes.
Thanks for the clarifications, but my point stands: I shouldn't have to dig into threads to find out how to use chromestatus for WebDriver. I am objecting to adding more process without proper documentation/guidance, and I think it ought to be improved sooner rather than later.