Skip to content
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

Closed
lread opened this issue Aug 1, 2022 · 0 comments · Fixed by #616
Closed

docs: link api fns to w3c webdriver endpoints #484

lread opened this issue Aug 1, 2022 · 0 comments · Fixed by #616
Labels

Comments

@lread
Copy link
Collaborator

lread commented Aug 1, 2022

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:

  • etaoin.api namespace docstring
  • api function docstrings
  • user guide

I'll play around and see what works.

@lread lread added the docs label Aug 1, 2022
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.
@lread lread mentioned this issue Aug 11, 2024
4 tasks
@lread lread closed this as completed in e58ff88 Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant