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>
Sigurd Schneider