Some files currently rely on the Protocol to be available on the
global scope. However, the Protocol definitions are defined in
a .d.ts file, which isn't available on runtime. Therefore,
attempting to import Protocol with non-type imports would retain
the imports in the `.js` files and break on runtime.
Since the only usages of the Protocol on runtime are the enums,
we can make them const, such that they get inlined as intended.
Then, `import * as` will work again, as the enums are inlined and
the import is removed from the `.js` file.
DISABLE_THIRD_PARTY_CHECK=Protocol update
R=jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I749e57c9f51596866b61cab686c59f00bc8a8eb4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897277
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>
Currently, all Protocol type definitions live on the global scope.
Additionally, the protocol files are included in all ts_library
targets. However, we don't want the protocol definitions to be
available in, for example, reusable UI components.
Therefore, we should move to a system where all files that want
to refer to the protocol types should import them instead.
However, doing so in 1 large CL will be problematic, which is
why it should be both globally available and importable as an
interim step.
To do so, we augment the existing protocol definitions to export
them as namespace and regular export. Then, we introduce a separate
file that imports the protocol types and augments the global scope
with the definitions. Now, protocol is both importable and remains
available on the global scope.
The reason that we need a separate file is that TypeScript disallows
you to augment the global scope in a file that also exports types.
Therefore, the global scope augmentation happens in protocol-globals.d.ts,
which will be removed once all Protocol type usages are imported.
To verify that this approach works, ProtocolClient imports the
required types, while SDK only imports it in AccessibilityModel.
All other files in SDK still refer to the global type.
In follow-up CLs, all pre-existing usages of Protocol will use
the import style.
DISABLE_THIRD_PARTY_CHECK=Updating protocol type format
R=szuend@chromium.org,jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I1d75949b9cd3e37989c6cddf79ac849f5664a1e3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2891756
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Throughout this process we learned the following:
- The magically generated agents need to be properly exposed
on the target, rather than setting them on the TargetBase prototype.
- We need to rename the protocol proxy api definitions to use
the invoke_ naming, such that we can use structured request bodies.
This will allow us to no longer rely on parameter ordering and
does not require additional changes to the underlying Closure
generated code.
- Instead of using a symbol as an index on a different class, use
a WeakMap to keep track of the link between the NetworkRequest
and the NetworkManager. This breaks the circular dependency and
allows us to remove the lookup with the symbol
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: I6cf25533b32793636d970b0a6c108f739d4e757e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2167868
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Even though we were using the SDK files in the unittests for SDK,
not all files were included. A CL which attempts to use sdk.js (e.g.
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2165757)
would then fail on several generated .d.ts issues.
Issues fixed:
- Usage of `Object` instead of `Map` causing issues with a type
alias of `string`, since TypeScript object notation only allows
primitives to be used as indices.
- Missing return types for function types
- A reference to `Protocol.NetworkAgent` which does not exist on
the protocol. Instead, that is part of the protocol-proxy-api.
Therefore, we must include the declaration file in the ts_library.
This also showed that the `ProtocolApi` needs to be exported
instead of declared.
This means that for any future reference to any Protocol type
that is actually an agent, we should be using the
`ProtocolProxyApi` definitions instead. To make sure Closure
understands that type, I aliased it in the externs.
R=jacktfranklin@chromium.org
CC=sigurds@chromium.org,szuend@chromium.org
DISABLE_THIRD_PARTY_CHECK=Typescript fixes
No-Presubmit: true
Bug: 1011811
Change-Id: I4f5a488edb2d5fa6c5ed12d33411efb5f7fb8133
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2165795
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commands, Events and Object types can declare "inline enums" to
restrict the possible values of a 'string' field.
Example field:
referrerPolicy: ('unsafe-url'|'...'|'...')
To enable type-checking with TypeScript and stay compatible with
existing code, we now generate explicit enums. The naming scheme
for the enum names is adapted from code_generator_frontend.py
and needs to always match.
Example generated enum for the above code:
export enum RequestReferrerPolicy {
UnsafeUrl = 'unsafe-url',
NoReferrerWhenDowngrade = 'no-referrer-when-downgrade',
NoReferrer = 'no-referrer',
Origin = 'origin',
OriginWhenCrossOrigin = 'origin-when-cross-origin',
SameOrigin = 'same-origin',
StrictOrigin = 'strict-origin',
StrictOriginWhenCrossOrigin = 'strict-origin-when-cross-origin',
}
This is necessary as we didn't had any type for this enum before
but existing code was using
Protocol.Network.RequestReferrerPolicy
as a type in JSDoc.
R=tvanderlippe@chromium.org
Bug: chromium:1011811
Change-Id: I4b4aa04b69fa4d7bf3b79ad97d61d4e3bfb7e228
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2113374
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Instead of
export type MixedContentType = ('blockable'|'...'|'none');
we know emit
export enum MixedContentType {
Blockable = 'blockable',
OptionallyBlockable = 'optionally-blockable',
None = 'none',
}
This is necessary as existing JavaScript code accesses these
enums using
Protocol.Security.MixedContentType.None
R=tvanderlippe@chromium.org
Bug: chromium:1011811
Change-Id: Id4bf2c1333affcdc4df37a43bf95379700e3e9d0
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2113373
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This improves the PRESUBMIT performance as we can rely on the AST
parsing of ESLint, meaning we don't have to parse AST twice.
It also allows us to use the nice `--fix` solution to insert the proper
license header in the files.
This shaves an expected 5 seconds of the presubmit time
(non-scientifically computed based on 2 uploads).
Change-Id: I5c53e9b232585f9ec46f86b36557c50bf80f7add
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2097992
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Tim van der Lippe