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

feat: use CDP's auto-attach mechanism #8520

Merged
merged 10 commits into from Jul 21, 2022
Merged

feat: use CDP's auto-attach mechanism #8520

merged 10 commits into from Jul 21, 2022

Conversation

OrKoN
Copy link
Collaborator

@OrKoN OrKoN commented Jun 14, 2022

In this PR, we refactor Puppeteer to make use of the CDP's auto-attach mechanism. This allows the backend to pause
new targets and give Puppeteer a chance to configure them properly. This fixes the flakiness related to dealing with
OOPIFs and should fix some other issues related to the network interception and navigations. If those are not fixed completely by this PR, the PR serves a solid base for fixing them.

Closes #8507, #7990
Unlocks #3667

BEGIN_COMMIT_OVERRIDE
feat: use CDP's auto-attach mechanism
BREAKING CHANGE: With Chromium, Puppeteer will now attach to page/iframe targets immediately to allow reliable configuration of targets.
END_COMMIT_OVERRIDE

BREAKING CHANGE: With Chromium, Puppeteer will now attach to page/iframe targets immediately to allow reliable configuration of targets.

@OrKoN OrKoN force-pushed the waitForDebugger branch 6 times, most recently from c96f7f6 to 5eaa531 Compare June 15, 2022 10:59
@OrKoN OrKoN force-pushed the waitForDebugger branch 23 times, most recently from a0cec05 to a6a59a5 Compare June 28, 2022 09:16
@OrKoN OrKoN changed the title chore: wip waitForDebugger auto-attach feat: use CDP's auto-attach mechanism Jun 28, 2022
@OrKoN OrKoN merged commit a9fe19c into main Jul 21, 2022
@OrKoN OrKoN deleted the waitForDebugger branch July 21, 2022 18:50
OrKoN added a commit that referenced this pull request Jul 22, 2022
* feat: use CDP's auto-attach mechanism

In this PR, we refactor Puppeteer to make use of the CDP's auto-attach mechanism. This allows the backend to pause
new targets and give Puppeteer a chance to configure them properly. This fixes the flakiness related to dealing with
OOPIFs and should fix some other issues related to the network interception and navigations. If those are not fixed completely by this PR, the PR serves a solid base for fixing them.

Closes #8507, #7990
Unlocks #3667

BREAKING CHANGE: With Chromium, Puppeteer will now attach to page/iframe targets immediately. Browser.connect requires an explicit product name when connecting to Firefox since Firefox does not support CDP's auto-attach.
OrKoN added a commit that referenced this pull request Aug 2, 2022
This PR implements automatic detection of the Firefox product when the `.connect()` method is used. This partially undoes the breaking change in #8520 but it's also a breaking change on its own since we don't accept an explicit product name anymore (it does not look like it was used anyway).
jrandolf pushed a commit that referenced this pull request Aug 2, 2022
* feat: use CDP's auto-attach mechanism

In this PR, we refactor Puppeteer to make use of the CDP's auto-attach mechanism. This allows the backend to pause
new targets and give Puppeteer a chance to configure them properly. This fixes the flakiness related to dealing with
OOPIFs and should fix some other issues related to the network interception and navigations. If those are not fixed completely by this PR, the PR serves a solid base for fixing them.

Closes #8507, #7990
Unlocks #3667

BREAKING CHANGE: With Chromium, Puppeteer will now attach to page/iframe targets immediately to allow reliable configuration of targets.
jrandolf pushed a commit that referenced this pull request Aug 2, 2022
This PR implements automatic detection of the Firefox product when the `.connect()` method is used. This partially undoes the breaking change in #8520 but it's also a breaking change on its own since we don't accept an explicit product name anymore (it does not look like it was used anyway).
OrKoN added a commit that referenced this pull request Sep 13, 2022
With #8520 Puppeteer is now aware of all targets it connects
to. In order to have a not flaky init, Puppeteer waits for
all existing targets to be configured during the connection process.
This does not work well in case of concurrent connections because
while one connection might initializing a target the other one
might be closed it. In general, that is expected because we
can only be eventually consistent about the target state but we
also should not crash the init if some targets have been closed.
This PR implements checks to see if the errors are caused by the
target or session closures and supresses them if it's the case.
OrKoN added a commit that referenced this pull request Sep 13, 2022
With #8520 Puppeteer is now aware of all targets it connects
to. In order to have a not flaky init, Puppeteer waits for
all existing targets to be configured during the connection process.
This does not work well in case of concurrent connections because
while one connection might initializing a target the other one
might be closed it. In general, that is expected because we
can only be eventually consistent about the target state but we
also should not crash the init if some targets have been closed.
This PR implements checks to see if the errors are caused by the
target or session closures and supresses them if it's the case.
OrKoN added a commit that referenced this pull request Sep 13, 2022
With #8520 Puppeteer is now aware of all targets it connects
to. In order to have a not flaky init, Puppeteer waits for
all existing targets to be configured during the connection process.
This does not work well in case of concurrent connections because
while one connection might initializing a target the other one
might be closed it. In general, that is expected because we
can only be eventually consistent about the target state but we
also should not crash the init if some targets have been closed.
This PR implements checks to see if the errors are caused by the
target or session closures and supresses them if it's the case.
OrKoN added a commit that referenced this pull request Sep 14, 2022
With #8520 Puppeteer is now aware of all targets it connects
to. In order to have a not flaky init, Puppeteer waits for
all existing targets to be configured during the connection process.
This does not work well in case of concurrent connections because
while one connection might initializing a target the other one
might be closed it. In general, that is expected because we
can only be eventually consistent about the target state but we
also should not crash the init if some targets have been closed.
This PR implements checks to see if the errors are caused by the
target or session closures and supresses them if it's the case.
OrKoN added a commit that referenced this pull request Sep 14, 2022
With #8520 Puppeteer is now aware of all targets it connects
to. In order to have a not flaky init, Puppeteer waits for
all existing targets to be configured during the connection process.
This does not work well in case of concurrent connections because
while one connection might initializing a target the other one
might be closed it. In general, that is expected because we
can only be eventually consistent about the target state but we
also should not crash the init if some targets have been closed.
This PR implements checks to see if the errors are caused by the
target or session closures and supresses them if it's the case.
jrandolf pushed a commit that referenced this pull request Sep 15, 2022
With #8520 Puppeteer is now aware of all targets it connects
to. In order to have a not flaky init, Puppeteer waits for
all existing targets to be configured during the connection process.
This does not work well in case of concurrent connections because
while one connection might initializing a target the other one
might be closed it. In general, that is expected because we
can only be eventually consistent about the target state but we
also should not crash the init if some targets have been closed.
This PR implements checks to see if the errors are caused by the
target or session closures and suppresses them if it's the case.
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.

[Bug]: Puppeteer doesn't capture some OOPIF requests (Flaky)
2 participants