This PR fixes the following edge case:
- `const oldPromise = world.puppeteerUtil`.
- setContext occurs but context is immediately destroyed, i.e.
`world.#puppeteerUtil === oldPromise` is not resolved.
- clearContext occurs due to destruction, i.e. `world.#puppeteerUtil` is
replaced (`world.#puppeteerUtil !== oldPromise`).
- `oldPromise` never resolves.
Since we moved to the central binaries cache it does not make sense to
clean up old binaries automatically because multiple installations can
use different versions. We expect the users to clean the cache from time
to time until we offer a CLI for managing the browsers.
Closes#9533
Issue: #9394
**What kind of change does this PR introduce?**
Feature - Added support of the `referrerPolicy` parameter (from CDP's
`Page.navigate`) to Puppeteer's `page.goto`.
**Did you add tests for your changes?**
No, currently it has no meaning that isn't browser implementation based,
which might get broken in the future. If there are suggestions to tests,
please let me know so I'll add them.
**If relevant, did you update the documentation?**
Yes, the documentation of the `goto` method has been updated.
**Summary**
I wanted to contribute to this project, which I used for testing on our
environment and saw issue #9394, so I decided to resolve it :)
**Does this PR introduce a breaking change?**
No. I added the `referrerPolicy` as an optional parameter, which will
use the HTTP header `Referrer-Policy` if not provided (much like the
`referer` parameter) so it will not interfere.
Co-authored-by: Ophir Back <ophir.back@broadcom.com>
The only drawback of adding overrides is that our documentation
generator would generate a page for each overload which might be hard to
read/find on the documentation website.
Closes#9512#9385
<!-- Thanks for submitting a pull request! Please provide enough
information so that others can review your pull request. -->
**What kind of change does this PR introduce?**
types fix
**Did you add tests for your changes?**
No
**If relevant, did you update the documentation?**
Not relevant
**Summary**
I am updating `import`s of `devtools-protocol` to always use named
import instead of the default.
For some reason, typescript doesn't understand when it is imported as
default.
```
node_modules/puppeteer-core/lib/esm/puppeteer/common/TargetManager.d.ts:23:59 - error TS2694: Namespace '"/Users/kyrylo/pacakge/node_modules/puppeteer-core/node_modules/devtools-protocol/types/protocol"' has no exported member 'Target'.
23 export declare type TargetFactory = (targetInfo: Protocol.Target.TargetInfo, session?: CDPSession) => Target;
~~~~~~
Found 1 error in node_modules/puppeteer-core/lib/esm/puppeteer/common/TargetManager.d.ts:23
```
**Does this PR introduce a breaking change?**
No
<!-- If this PR introduces a breaking change, please describe the impact
and a migration path for existing applications. -->
**Other information**
I am updating `import`s of `devtools-protocol` to always use named
import instead of the default.
**What kind of change does this PR introduce?**
Add how to disable timeout for `page.pdf()`.
**Summary**
This was mentioned in the PR that adding this feature
https://github.com/puppeteer/puppeteer/pull/7508 But it has lost at
https://github.com/puppeteer/puppeteer/pull/8593.
I'm not sure why this was removed, but I think this info is useful for
users.
**Does this PR introduce a breaking change?**
no
**What kind of change does this PR introduce?**
Typo fix in the documentation
**Did you add tests for your changes?**
No
**If relevant, did you update the documentation?**
N/A
**Summary**
I spotted the `Visible` parameter had an uppercase `V` in the [Remarks
section of the Page.waitForSelector API
documentation](https://pptr.dev/api/puppeteer.page.waitforselector#remarks).
Updated this to the lowercase `v` in the relevant places (source,
documentation, versioned version of the doc page).
While doing this, I also spotted there was an extra space in `are :` in
the sentence above – so changed that as well.
**Does this PR introduce a breaking change?**
No
**Other information**
I’ve confirmed the parameter is spelled correctly on
https://pptr.dev/api/puppeteer.waitforselectoroptions. I’m not sure why
the documentation for those properties is in two places with slightly
different wording – but to me it felt useful to see this directly on the
method’s API docs.
Issue: #1313
<!-- Thanks for submitting a pull request! Please provide enough
information so that others can review your pull request. -->
**What kind of change does this PR introduce?**
Feature.
**Did you add tests for your changes?**
Yes.
**If relevant, did you update the documentation?**
Yes.
**Summary**
Supports keyboard shotcuts on MacOS. See Chrome Devtools Protocol
document:
https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-dispatchKeyEvent.
**What kind of change does this PR introduce?**
I have browsers pool in some cloud. I want that only users with access
will be able to connect to them. So they must provide token through
headers. But puppeteer does not allow to send headers when connected to
browser by ws connection. So I added this feature.
Closes#7218
**What kind of change does this PR introduce?**
Better type inference.
**Did you add tests for your changes?**
~Not yet.~ Yes.
**If relevant, did you update the documentation?**
Not yet.
**Summary**
<!-- Explain the **motivation** for making this change. What existing
problem does the pull request solve? -->
<!-- Try to link to an open issue for more information. -->
Currently methods that return an element handle, i.e. `.$`,
`.waitForSelector` attempt to infer the node element type from the
selector string. However, this only works when the selector is an exact
match of the element tag, i.e. a selector `"a"` would be inferred as
`HTMLAnchorElement` . And not when the selector is complex, i.e.
selectors `"a#some-id"`, `div > a`, `a:nth-child(2)` would all fallback
on `Element`.
This is due to simply looking up the the selector in
`HTMLElementTagNameMap` and `SVGElementTagNameMap` without any attempt
to parse the selector string.
This PR is an attempt to do so.
**Does this PR introduce a breaking change?**
<!-- If this PR introduces a breaking change, please describe the impact
and a migration path for existing applications. -->
This could break existing incorrect assertions using the `as` keyword.
**Other information**
~This PR introduces a dependency on the `type-fest` package.~
This PR is far from complete (no tests, no docs). Put out early for
feedback and discussion.
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
