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
fix: extends ElementHandle
to Node
s
#8552
Conversation
234aaf3
to
83ca4ef
Compare
In what cases can an ElementHandle contain a Node? |
See |
479d398
to
0c684ee
Compare
1df828f
to
d9846f1
Compare
are any updates needed for api.md for these changes? |
12d3fb2
to
36d4f72
Compare
There are a lot of updates for |
@jrandolf wdyt about doing a release now (I assume previous PRs don't need api.md changes) and postponing landing this until the documentation is ready? Today or tomorrow we also need to roll M104 which would be nice to release as soon as possible too so I would not like to block a release on anything. |
b965ef3
to
c07ca6c
Compare
a7a70a0
to
083b6fc
Compare
fce1d39
to
9099f7b
Compare
ElementHandle<Node>
return types.ElementHandle
to Node
s
ElementHandle
to Node
sElementHandle
to Node
s
I used to use page.$x(expression) and elementHandle.click([options]) with puppeteer v13.4 just fine. import puppeteer from 'puppeteer';
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
const handles = await page.$x('xpath');
await handles[0].click(); But now since the API signatures have changed ($x(expression) and click(this, options)), the above usage ends up with the following
How shall I transit from using |
I was able to get away with this problem by type casting. await (handles[0] as ElementHandle<Element>).click(); Turns out it in fact still works at runtime and only bugs me during compile time. It's not pretty, but it works. :/ |
This PR adjusts some incorrect types within Puppeteer:
ElementHandle
is nowNode
instead ofElement
.ElementHandle
is stillElement
.QueryHandler
s now useNode
types.