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

Implement basic versions of Page.Keyboard #52

Merged
merged 8 commits into from
May 31, 2024
Merged

Conversation

germsvel
Copy link
Contributor

What changed?

We implement a basic version of Page.Keyboard functions whose specs were commented out in the module.

The test cases are the simplest versions I could come up with (having borrowed heavily from Python's keyboard tests)

The implementation also follows Python's implementations.

Noteworthy Highlights

  1. Our implementation takes a %Page{} struct rather than what the specs suggested (a Keyboard.t()). I don't know if it's possible to pass down a narrower type, but as far as I could tell Page had both the session and guid (which are needed for the Channel.post call).

  2. We namespace Playwright.Keyboard under Page (i.e. Playwright.Page.Keyboard) to match the directory structure and since that seems to match the Playwright documentation as well.

  3. Finally, we add a new test/assets/ directory where we include a new inputs/keyboard.html page. That page is copied directly from Python, so it follows Python's style of testing. In particular, our tests needed the getResult() function to get the values back for our test assertions.

@coreyti coreyti self-assigned this May 30, 2024
What changed?
=============

We implement a basic version of `Page.Keyboard` functions whose specs
were commented out in the module.

The test cases are the simplest versions I could come up with (having
borrowed heavily from [Python's keyboard tests])

The implementation also follows [Python's implementations].

[Python's keyboard tests]: https://github.com/microsoft/playwright-python/blob/2402e1283de6049cb66ea8ec6f303ba681890d2a/tests/async/test_keyboard.py#L1
[Python's implementations]: https://github.com/microsoft/playwright-python/blob/2402e1283de6049cb66ea8ec6f303ba681890d2a/playwright/_impl/_input.py#L25-L38

Noteworthy Highlights
----------------------

1. Our implementation takes a `%Page{}` struct rather than what the
   specs suggested (a `Keyboard.t()`). I don't know if it's possible to
   pass down a narrower type, but as far as I could tell `Page` had both
   the `session` and `guid` (which are needed for the `Channel.post`
   call).

2. We namespace `Playwright.Keyboard` under `Page` (i.e.
   `Playwright.Page.Keyboard`)  to match the directory structure and
   since that seems to match the Playwright documentation as well.

3. Finally, we add a new `test/assets/` directory where we include a new
   `inputs/keyboard.html` page. That page is [copied directly from
   Python][keyboard.html], so it follows Python's style of testing. In
   particular, our tests needed the `getResult()` function to get the
   values back for our test assertions.

[keyboard.html]: https://github.com/microsoft/playwright-python/blob/2402e1283de6049cb66ea8ec6f303ba681890d2a/tests/assets/input/keyboard.html#L1
A reasonable idea, but unnecessary:

The [`playwright-assets`](https://github.com/mechanical-orchard/playwright-assets)
dependency provides all of the test assets. Indeed, the `keyboard.html` file
that was being utilized in the new keyboard tests is that from the
`playwright-assets` server, and not this (removed) file in `test/assets`.
For the time being, Node packages are installed directly into `priv/static`,
and utilized from there. This is not the desired long-term solution, but is
what is needed for the moment.
200ms allows for some flakiness. Most things will still finish faster. If the
event doesn't happen in 500ms, that's probably interesting, finally.
@coreyti
Copy link
Member

coreyti commented May 31, 2024

Hey @germsvel, thanks for the contribution!

I made some adjustments in commits:

Those are worth a quick look. And, any feedback/suggestions based on those would be great.

The other 4 commits are not directly related to your changes, but came along in my rebasing (the PR revealed some missing changes needed). I've decided to be okay with having those "tag along" with your PR 🤷🤩

All that said, I'm happy to merge your change. Please continue. 🙂

@coreyti coreyti merged commit c9be743 into main May 31, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants