-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Improve generalized/sourcemap fetcher #12070
Comments
It does #12044 (comment) |
|
What are y'all thinking for a timeline for this? Stable is now m89, earliest #12199 could land is m91, so the main reason to hold back is CLI users using an old stable Chrome/specific Chromium build? |
yea, exactly. It seems people using docker images are eternally a few more versions behind than you'd expect.. v8? |
https://proxx.app/ also reproduces this behavior. |
#9459 landed our generalized fetcher (with an iframe).
We may have some areas where it can be improved.
CSP sensitivity.. I didn't test, but I believe a
frame-src
directive would introduce problems for this technique.content-type sensitivity. In #12064 we see that if a map is served with
application/octet-stream
it'll trigger a user-visible download while Lighthouse is fetching it. DevTools, meanwhile, doesn't have that behavior when it fetches.devtools generalized loading…
There's been some updates..
Sigurd added the
Network.loadNetworkResource
protocol method for sourcemaps. He recently added metrics to record how various load attempts succeed/fail.AFAICT, there are currently four different types of fetch attempts... you can see them in
PageResourceLoader.js
's_dispatchLoad()
in the devtools source.Here's the umbrella crbug.
You can also see some of this in the new "Developer Resources" drawer panel in devtools:
The text was updated successfully, but these errors were encountered: