In https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2102717
we are updating the Karma configuration to use the Ninja output for
all unittests. This CL includes all existing unittests in relevant
ts_library definitions and adds the corresponding (previously missed)
dependencies as ts_library as well.
Since most of these dependencies are actually not compiling with
the TypeScript compiler (the original intent of the CL linked above),
we are adding the @ts-nocheck annotation for now. Of course, we should
remove these annotations as soon as possible, but that is a bit more
work, as the tests involved are primarily UI driven.
R=jacktfranklin@chromium.org
# Windows presubmit breaks with large CLs
No-Presubmit: true
Bug: 1061125
Change-Id: Ic67dbbc805642eaa618340a67ea0975eaacffc24
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2162850
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@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
Mathias Bynens