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
Request interception with caching (rev 8695759) fails when loading stylesheet-initiated fonts (?) #7038
Comments
In addition, I have added a few more lines to the above testing JavaScript code to add a new mode which configures request interception via CDP directly than via Puppeteer. The updated JS code and the recorded CDP debugging details have been uploaded here: https://gist.github.com/starrify/b1d0d632006aa3ed4288950e1d13fe21 With the new direct-CDP mode, the request interception indeed works properly with caching enabled upon rendering the same web page: still Chrome emits twice the Some details:
|
As illustrated above in this issue report, the newly observed Chrome behavior of possibly multiple request pauses (the The problem, as I assume, comes from Puppeteer's design / implement of its
Due to the complexity of the design, the network manager code then assumes a strict one-to-one relation of the two upstream events ( puppeteer/src/common/NetworkManager.ts Line 296 in b349c91
Therefore such code may be easily broken once multiple I would propose a backward-incompatible change to the API design as a solution, which is to separate Puppeteer's
|
Very nice analysis |
Can you confirm that https://github.com/Androbin/puppeteer/commit/36bba7000260da46ccec3eb1783ddbb7d9285dd6 fixes the issue? |
I have got some further studies on this very issue and here's a ticket created in the Chromium issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=1196004 , in which I further discussed the specific conditions that may trigger this double pausing issue, and attached a few minimal test cases for triggering that. @Androbin I appreciate your efforts and have responded in your pull request page some of my thoughts. |
It turns out that 2.4 is not strictly necessary in order to reproduce the issue. While it's true that this will help make the font delay the |
During testing I observed the following: |
Someone offered a workaround upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=1196004#c10
This seems to confirm that this issue is specific to fonts. |
See #6996 (comment) and #6996 (comment) for context. Issue: #7038
0. Overview
TL;DR:
1. Test Configuration
My tests are conducted with:
Node.js 14.16.0
andnpm 7.7.6
Here is a
Dockerfile
that may duplicate the exact test environment:Here is the sample JavaScript code I used to trigger the issue:
This script accesses https://github.com/ by default, while in practice I observed the same issue from several other frequently visited websites.
2. Tests and Results
From the above configurations one may set up the test environment and launch the quick test.
Here is an example of triggering the issue:
Here are the respective results per test:
Therefore the implement of 8695759 seems not fully functional, at least not for rendering https://github.com/ as tested.
3. Further Analysis
Thanks to Puppeteer's debugging ability, I tried to dump the CDP communication of the failed test via the below command:
In case that may save you some time, I've uploaded the recorded
8695759_caching_on.log
file here: https://gist.github.com/starrify/e1f5ad68c358b932890933be3fb2b736By comparing the URLs in the log file, it is observed that there are four
.woff
resources for fonts, all initiated by the stylesheets, that had theNetwork.requestWillBeSent
event but not aNetwork.responseReceived
:These four font resources are apparently not cached since the Docker container has a cold start. Also that's confirmed from the extracted CDP log file (e.g. no
Network.requestServedFromCache
event observed).Taking one resource
Alliance-No-1-SemiBold.woff
as an example for further inspection, I've got these from the log file:This suggests something interesting: for the same request (as identified by the
networkId
field), Chrome actually issued twice theFetch.requestPaused
event for some reason I do not yet know.While Puppeteer only manages to resume the first pause, such requests are therefore blocked forever.
In addition, since such resources are initiated in the stylesheets, having the requests pending indefinitely would block the browser from issuing the
Page.loadEventFired
event, therefore Puppeteer would also keep blocking on thepage.goto
line.The text was updated successfully, but these errors were encountered: