Update puppeteer to version 19.1.0+
#15865
Comments
|
Yikes! In the logs the following is visible: This is interesting since ENOENT seems to indicate the browser binary is missing somehow. The Puppeteer issue tracker has some pointers on this (https://github.com/puppeteer/puppeteer/search?q=enoent) but in general this can have a wide variety of causes. It's a bit more fortunate that this also seems to happen locally (I haven't tested it myself yet) because if we can reproduce this it will at least be easier to track down than if it were a bot-only issue... |
|
Looking at the error more closely, and also reproducing it locally now, the whole path mentioned there doesn't make sense at all. Firefox lives in a separate folder, not inside the Chrome folder, since during installation the following is logged for me locally: Therefore, the issue that Puppeteer 19.1.0+ are apparently trying to look for the Firefox binary in the wrong path :-/ |
|
I figured out that if we swap Firefox and Chrome in It's possible that this was actually already an issue in the way we create the browser sessions, but we were just lucky enough to never have it surface until recent internal changes in Puppeteer. In any case, this is fixable in our code (which leads me to believe our code is using an unintended way of spawing the browsers) since we have to wait until the browser is actually started before going to the next one. I already have a hothacked version working, but this will require a bit of refactoring that I want to think about more. |
|
I'm now 100% sure this is an upstream bug in Puppeteer and made a minimal reproducer to prove it. I have reported it to the Puppeteer issue tracker (see below) to get it fixed since it's a regression from a change made in version 19.1.0, which explains why we didn't run into it before. I think we should still start the browsers in series, but for now let's first await the upstream bugfix before we do so we can see how far we actually have to go once the upstream issue is fixed. |
|
Ugh, this is proving to be a far from trivial update. The original issue I filed upstream is fixed in Puppeteer 19.6.0, but that uncovered another very similar bug in Puppeteer that sadly also prevents us from updating :-( I made a reduced test case again for the Puppeteer team and I've reported it in the issue tracker (see below). Hopefully we can update without further problems once this bug is also fixed upstream. |
timvandermeij
changed the title
timvandermeij
changed the title
puppeteer to version 19.1.0+
|
It looks like we can proceed with this again now that the upstream issues have been fixed. I have Puppeteer 20 mostly working now if we start the browsers in series (which all in all seems like a better idea anyway and it's how Puppeteer expects that API to be used). However, I still need to do more testing and fix the cleanup of old browser revisions (which I ignored for now to first get the basics working) since the Puppeteer 20 APIs for that are sadly not complete yet. I have opened puppeteer/puppeteer#10174 for that, but fortunately I don't see that as a blocker since there seems to be a way around it; I mainly made the ticket to make the code on our side simpler since it feels like Puppeteer should provide this functionality out of the box, but for now we can do this ourselves to unblock the Puppeteer update which overall seems more important. I'll try to get this done next week. |
|
The Puppeteer team implemented the |
This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes mozilla#15865.
As can be seen from the first round of testing in PR #15864, trying to update Puppeteer beyond version
19.0.0completely breaks testing in Firefox. Curiously it does work locally when the--noChromeflag is being used, so it seems to be an issue with running tests in both Chrome and Firefox in parallel.We need to fix this, likely by making some adjustments to our test-suite, such that we don't get "stuck" on an older version of Puppeteer without being able to update. (A temporary work-around could also be to disable testing in Chrome.)
The text was updated successfully, but these errors were encountered: