Skip to content

Commit acf3b05

Browse files
committed
Merge remote-tracking branch 'origin/master' into navigate_history
2 parents 0665342 + a085d80 commit acf3b05

File tree

15 files changed

+9841
-7418
lines changed

15 files changed

+9841
-7418
lines changed

.gitattributes

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
# Automatically normalize line endings for all text-based files.
2+
* text=auto

.github/workflows/auto-publish.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ jobs:
77
deploy:
88
runs-on: ubuntu-20.04
99
steps:
10-
- uses: actions/checkout@v2
10+
- uses: actions/checkout@v3
1111
- uses: w3c/spec-prod@v2
1212
with:
1313
GH_PAGES_BRANCH: gh-pages

.github/workflows/test.yml

Lines changed: 38 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -7,22 +7,45 @@ on:
77
pull_request:
88

99
jobs:
10+
build:
11+
runs-on: ubuntu-20.04
12+
steps:
13+
- uses: actions/checkout@v3
14+
- uses: actions/setup-python@v3
15+
with:
16+
# Python 3.11 is broken: https://github.com/tabatkins/bikeshed/issues/2386
17+
python-version: "3.10"
18+
- name: Build spec without warnings
19+
run: ./scripts/build.sh --install
1020
cddl:
11-
runs-on: ubuntu-18.04
21+
runs-on: ubuntu-20.04
1222
steps:
13-
- uses: actions/checkout@v2
14-
- uses: actions/setup-node@v1
23+
- uses: actions/checkout@v3
24+
- uses: actions/setup-node@v3
25+
with:
26+
node-version: 16
27+
- name: Get cddl version
28+
run: curl -s https://crates.io/api/v1/crates/cddl | python3 -c "import sys, json; print(json.load(sys.stdin)['crate']['max_stable_version'])" | tee cddl.txt
29+
- name: "Cache rust binaries"
30+
uses: actions/cache@v3
31+
id: cache-cddl
32+
env:
33+
cache-name: cache-cddl
1534
with:
16-
node-version: 14.x
17-
- name: Install Dependencies
18-
run: npm install cddl parse5
19-
- name: Extract CDDL content from spec into files
20-
run: ./scripts/cddl/generate.js
21-
- name: Print remote.cddl
22-
run: cat remote.cddl
23-
- name: Print local.cddl
24-
run: cat local.cddl
35+
path: |
36+
~/.cargo/bin/
37+
~/.cargo/git/db/
38+
~/.cargo/registry/cache/
39+
~/.cargo/registry/index/
40+
./target/
41+
key: cddl-${{ hashFiles('cddl.txt') }}
42+
- uses: actions-rs/toolchain@v1
43+
with:
44+
toolchain: stable
2545
- name: Validate CDDL files
26-
run: |
27-
npx cddl validate local.cddl
28-
npx cddl validate remote.cddl
46+
run: ./scripts/test.sh
47+
- name: Archive CDDL files
48+
uses: actions/upload-artifact@v3
49+
with:
50+
name: cddl
51+
path: "*.cddl"

README.md

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,46 @@ WebDriver BiDi is a proposed bidirectional protocol for browser automation,
44
building on and extending [WebDriver](https://w3c.github.io/webdriver/).
55

66
WebDriver BiDi is not ready. Here's what we have so far:
7+
78
- An [explainer](./explainer.md) with more background and goals
9+
- A [roadmap](./roadmap.md) based on real-world end-to-end user scenarios
810
- Detailed [proposals](./proposals/) for the initial protocol
911
- A [unofficial spec draft](https://w3c.github.io/webdriver-bidi/) waiting to be fleshed out
12+
13+
## Status
14+
15+
[![test](https://github.com/w3c/webdriver-bidi/actions/workflows/test.yml/badge.svg)](https://github.com/w3c/webdriver-bidi/actions/workflows/test.yml)
16+
17+
## How to build the specification locally
18+
19+
We use [bikeshed](https://tabatkins.github.io/bikeshed/) to generate the specification.
20+
21+
Make sure you have the [right version of python](https://tabatkins.github.io/bikeshed/#install-py3) installed.
22+
23+
Now you can run in your terminal:
24+
25+
```bash
26+
./scripts/build.sh
27+
```
28+
29+
This script will install `bikeshed` (if not installed yet) and generate an
30+
`index.html` file for the specification.
31+
32+
Later on, you can use the `--upgrade` argument to force installing a newer version.
33+
34+
## How to generate CDDL locally
35+
36+
Make sure you have [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)
37+
and [rust](https://www.rust-lang.org/tools/install) installed.
38+
39+
Now you can run in your terminal:
40+
41+
```bash
42+
./scripts/test.sh
43+
```
44+
45+
This script will install required npm and cargo packages (if not installed yet)
46+
and generate the CDDL files for the remote end (`remote.cddl`) and the client
47+
(`local.cddl`).
48+
49+
Later on, you can use the `--upgrade` argument to force installing newer versions.

explainer.md

Lines changed: 49 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -1,49 +1,49 @@
1-
# Bidirectional WebDriver Protocol
2-
3-
## Overview
4-
5-
This document presents a possible design for a bidirectional WebDriver protocol, incorporating scenarios and resolutions discussed at the TPAC 2019 working group meeting. The protocol uses JSON-RPC messaging over WebSockets as the transport mechanism. WebDriver's current model of the browser is extended to include service workers and other non-page targets and make it possible for clients to target these additional contexts. We also discuss how the new protocol can interoperate with the existing protocol. Sample protocol messages illustrating how the protocol would work are included, and an JSON API specification is included alongside the document.
6-
7-
## Goals
8-
9-
The protocol is designed with the following goals in mind:
10-
11-
- **Support for the top customer scenarios identified at TPAC 2019:**
12-
- Listen for DOM events
13-
- Log what's going on in the browser including console and JS errors
14-
- Fail fast on any JS error
15-
- Mock backends and intercept network requests
16-
- Record traffic
17-
- Full-page screenshot
18-
- Access to native devtools protocol
19-
- Dynamic changes to iframe or documents
20-
- Performance timings
21-
- Notifying of new contexts
22-
- Bootstrap scripts
23-
- **Interoperability with classical WebDriver commands**
24-
- Allow existing test/automation code to be upgraded gradually.
25-
- **Feature parity with existing WebDriver commands**
26-
- Existing commands can be sent over the new protocol so that new test/automation code can be written entirely in the new protocol.
27-
- Update features to take advantage of bidi communication where appropriate. Useful for unhandled prompts and scenarios where polling is common.
28-
- **A machine and human-readable API specification**
29-
- Makes it easier to generate up-to-date language bindings, documentation, and test cases.
30-
- **Easily mappable to/from native devtools protocols**
31-
- Simple for browser vendors to implement and maintain.
32-
- Possible for clients to enhance their WebDriver automation with browser-specific devtools protocol features.
33-
34-
This document doesn't attempt to dive into the any of the new feature scenarios identified above, but rather tries to provide a solid foundation and the necessary primitives to build these features on. The document does walk through an example of an existing WebDriver feature (unhandled prompts) being updated for a bidirectional world.
35-
36-
## Proposals
37-
38-
- [Core Functionality](./proposals/core.md)
39-
- [Bootstrap Scripts](./proposals/bootstrap-scripts.md)
40-
41-
[openrpc.json](./proposals/openrpc.json) contains an OpenRPC specification with an initial set of proposed commands and events.
42-
43-
## References
44-
45-
1. [WebDriver](https://w3c.github.io/webdriver/)
46-
2. [JSON-RPC 2.0 Specification](https://www.jsonrpc.org/specification)
47-
3. [OpenRPC Specification](https://spec.open-rpc.org/)
48-
4. [Browser Tools- and Testing WG, Day 1, TPAC 2019, Fukuoka](https://www.w3.org/2019/09/19-webdriver-minutes.html)
49-
5. [Browser Tools- and Testing WG, Day 2, TPAC 2019, Fukuoka](https://www.w3.org/2019/09/20-webdriver-minutes.html)
1+
# Bidirectional WebDriver Protocol
2+
3+
## Overview
4+
5+
This document presents a possible design for a bidirectional WebDriver protocol, incorporating scenarios and resolutions discussed at the TPAC 2019 working group meeting. The protocol uses JSON-RPC messaging over WebSockets as the transport mechanism. WebDriver's current model of the browser is extended to include service workers and other non-page targets and make it possible for clients to target these additional contexts. We also discuss how the new protocol can interoperate with the existing protocol. Sample protocol messages illustrating how the protocol would work are included, and an JSON API specification is included alongside the document.
6+
7+
## Goals
8+
9+
The protocol is designed with the following goals in mind:
10+
11+
- **Support for top customer scenarios:**
12+
- Listen for DOM events
13+
- Log what's going on in the browser including console and JS errors
14+
- Fail fast on any JS error
15+
- Mock backends and intercept network requests
16+
- Record traffic
17+
- Full-page screenshot
18+
- Access to native devtools protocol
19+
- Dynamic changes to iframe or documents
20+
- Performance timings
21+
- Notifying of new contexts
22+
- Bootstrap scripts
23+
- **Interoperability with classical WebDriver commands**
24+
- Allow existing test/automation code to be upgraded gradually.
25+
- **Feature parity with existing WebDriver commands**
26+
- Existing commands can be sent over the new protocol so that new test/automation code can be written entirely in the new protocol.
27+
- Update features to take advantage of bidi communication where appropriate. Useful for unhandled prompts and scenarios where polling is common.
28+
- **A machine and human-readable API specification**
29+
- Makes it easier to generate up-to-date language bindings, documentation, and test cases.
30+
- **Easily mappable to/from native devtools protocols**
31+
- Simple for browser vendors to implement and maintain.
32+
- Possible for clients to enhance their WebDriver automation with browser-specific devtools protocol features.
33+
34+
This document doesn't attempt to dive into the any of the new feature scenarios identified above, but rather tries to provide a solid foundation and the necessary primitives to build these features on. See [the roadmap](roadmap.md) for some example real-world user scenarios we aim to enable.
35+
36+
## Proposals
37+
38+
- [Core Functionality](./proposals/core.md)
39+
- [Bootstrap Scripts](./proposals/bootstrap-scripts.md)
40+
41+
[openrpc.json](./proposals/openrpc.json) contains an OpenRPC specification with an initial set of proposed commands and events.
42+
43+
## References
44+
45+
1. [WebDriver](https://w3c.github.io/webdriver/)
46+
2. [JSON-RPC 2.0 Specification](https://www.jsonrpc.org/specification)
47+
3. [OpenRPC Specification](https://spec.open-rpc.org/)
48+
4. [Browser Tools- and Testing WG, Day 1, TPAC 2019, Fukuoka](https://www.w3.org/2019/09/19-webdriver-minutes.html)
49+
5. [Browser Tools- and Testing WG, Day 2, TPAC 2019, Fukuoka](https://www.w3.org/2019/09/20-webdriver-minutes.html)

0 commit comments

Comments
 (0)