-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: link api fns to w3c webdriver endpoints #484
Labels
Comments
lread
added a commit
that referenced
this issue
Aug 11, 2024
We've been using a `capabilities` syntax for create session that has long been deprecated. Firefox finally forced our hand with geckodriver 0.35.0, which has removed support for the obsolete syntax. All supported WebDrivers understand the newer syntax. We used to pass capabilities in as `desiredCapabilities`, we now pass them in as a single item in the `firstMatch` vector. This should match existing behaviour. Moving to the new capabilities syntax tells `chromedriver` (and `msedgedriver`) that we are running in "w3c mode". This has benefits on Etaoin code. Our many customizations for these WebDrivers are no longer necessary, they now support the W3C WebDriver endpoint spec. In "w3c mode", chromedriver disallows any endpoints that could be served by W3C WebDriver endpoints. Notable examples are mouse and touch operations. These are now handled by the W3C WebDriver action endpoints. WebDriver actions are not stand-alone, they are submitted as transaction of steps. As such the following Chrome-specific fns are no longer needed and would be confusing if not deleted: - `mouse-btn-down` - `mouse-btn-up` - `with-mouse-btn` - `mouse-move-to` (was also available in Firefox) - `mouse-click` - `right-click` - `left-click` - `touch-down` - `touch-move` - `touch-up` Users will instead express these manipulations via the existing `perform-actions`. Fns that represent a transaction of actions in themselves remain: - `drag-and-drop` (from element to element) - `double-click*` (on an element) - `*-click-on` (on an element) - `touch-tap` (on an element) Verifying that everything worked required a full review of the API. Some sweeping changes: - Our recent deletion of PhantomJS support allowed me to streamline many `defmulti`s into `defn`s. - Added links to W3C WebDriver Spec endpoints to docstrings Added some fns to expose at the W3C WebDriver Spec granularity: - `get-timeouts` - `set-timeouts` - `get-element-rect` - `get-element-rect-el` - `get-element-rect` - `set-window-rect` - `get-window-rect` We have finer grained versions of the above (ex. `get-element-position`, `get-element-size`, etc). We've kept these for backwards compatibility, but if we were starting today, we would have just matched today's W3C WebDriver spec. Minor fixes/changes: - Uncomment and fix the maximize test - Screenshots on elements work on safari, enable them - Added notes on displayedness to docstrings - Remove internal support for undocumented `:desired-capabilities`, the implementation was either ultra legacy or misunderstood legacy APIs. Add `bb test-coverage` task to check what we are not covering with tests New tests include coverage for: - `back` - `forward` - `set-cookie` - `release-actions` - `*-timeout*` - `double-click` Closes #467 Incidentally closes #522 via better docstrings on getting properties. Closes #484 with W3C WebDriver spec endpoint links.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be useful if we were to link our etaoin.api functions to w3c webdriver endpoints (or vice versa).
This would encourage us to track our endpoint coverage and allow folks to click through for gritty details.
Candidate spots:
I'll play around and see what works.
The text was updated successfully, but these errors were encountered: