This CL introduces an initiator object for loads that go through
the PageResourceLoader. This enables the page resource loader to
forbid certain resource loads based on the URL of the resource and
the URL of the initiator. This is important, for example, for loading
extension source maps.
Bug: chromium:974543
Change-Id: If2b1d8f93be60ad0d3ca8261074b92625ed58c02
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2339316
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
This introduces a singleton PageResourceLoader and refactors loading of
additional developer resources to go through the loader. The loader
keeps track of all resources that get loaded, together with potential
load errors. If we ever decide to use a different method for loading
resources, we only need to change the PageResourceLoader.
Additionally, the loader limits the number of concurrent requests to
500, so as to not overload the backend. This is important, because
there is a limit of 2700 concurrent requests in the network stack -
if that limit is reached, additional requests will fail. Previously,
we introduced code in the back-end that retries requests, but this is
not a good approach, because only DevTools requests are retried.
Doing the rate limiting in the front-end has the downside that multiple
DevTools sessions don't have a shared limit, but simplifies the require-
ments for the back-end, so we think it is a good trade-off.
Bug: chromium:1069378
Change-Id: I05a9f3c79c685347c1e48b30c49f56801ae39fc3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2270537
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
To enable full parallelization of all files in sdk/, we can add the
@ts-nocheck annotation to all files. This suppresses existing
TypeScript errors in these files.
We can then one-by-one remove these annotations and fix the issues
reported in these files. This allows us to parallelize the work
and work on many files at the same time.
As a starter, I typechecked sdk/Connections.js to verify that
typechecking works while all other files are not checked yet.
I did do so by locally suppressing all TypeScript errors in
SDKModel.js and remove the `instance` method on `TargetManager`.
I then confirmed that rebuilding with TypeScript correctly
fails on the missing method, but does not require SDKModel.js
itself to be typechecked.
Bug: 1011811
Change-Id: I46de3839f7d837e951967dd932218bda00c6ad5b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2156352
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This CL adds reporting of a human readable string which includes the
internal error code if a source map load fails. We could think about
providing a web.dev page with an explanation of the internal error
codes. In any case, this fine-grained distinction should be an
improvement for referencing errors on sites like stack-overflow. If
all else fails, the internal error code can be looked up in
net_error_list.h in the chromium sources.
Screenshot: https://imgur.com/a/dWjG1GS
Bug: chromium:1030746
Change-Id: I04ddbc3f98ab2d6c54fb067a89408cbb60217477
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1998761
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
The source editor, when it cannot load a particular file, will simply
display a blank file instead. At the bottom, this is because the APIs
used to load the files do not have a way to propagate an error up to
the call site. Rather, the callback either is never called, or is
called with just an empty string.
This refactor changes the way the project system loads file contents
by replacing the callback model with a Promise-based model. However,
in this version, rather than propagating an error (handled via
catch), the error is exposed as a property on the object passed via
the the load functions. Although it might be preferable to use
async throw/catch, because there are ~4-5 layers of redirection
through the project system, the added complexity seems to not really
justify that work. I'm open to reconsidering this design, though.
Attempting to load a file via file:// which does not exist previously
produced no error because the DevToolsUIBindings handler would just
always resolve with no content and HTTP status 200. I had previously
addressed that bug in this changeset, but I've split it out to
https://chromium-review.googlesource.com/c/chromium/src/+/1847833 .
Sample "after" screenshot: https://imgur.com/a/tlm90sg
Bug: 961940
Bug: 941035
Change-Id: If121611090e9c35eeb1de162b59f8a9f72f696d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1817677
Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
Reviewed-by: Jeff Fisher <jeffish@microsoft.com>
Commit-Queue: Lorne Mitchell <lomitch@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#705438}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 61ec2a233d9a7bf4bb4b3e610de6fc233ae0d46e
Benedikt Meurer