During the TypeScript migration, we are moving to reference singleton
instances, rather than the `sharedInstance` lookup in the runtime.
However, the sharedInstance wasn't aware of the singletons being
declared in (most notably) the panels. Therefore, it is possible
that developers migrate to the singleton pattern and consequently
cause two panels to be constructed.
To prevent this from happening, we update `sharedInstance` to lookup
the `instance` as declared on the type, if it exists. If it does,
it calls that function. This makes sure that singletons declared
won't break the Runtime/module.json setup that already exists.
For all panels/classes that perform the `sharedInstance` invocation
in their own declared `instance` method, we migrate to singletons
straight away. Otherwise, we end up with a StackOverflow where
both methods call each other.
R=aerotwist@chromium.org
Bug: 1131423, 1011811
Change-Id: Ice7d2f59114b9aaa8ddd8d24f7eefc7aa880ff4e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2428897
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
At the moment the Runtime loading code, fetchResource, assumes the same
root as the hosting module, i.e. if Lighthouse is on devtools/bundled,
it assumes that the loaded resource will also be on devtools/bundled.
This assumption does not hold true for Lighthouse loading its
localization files, which are held on devtools/remote. The Runtime
module currently provides a function for loading a binary resource, and
this CL adds an equivalent function for loading text resources, with the
expectation that modules like Lighthouse can use this to fetch remote
resources.
R=jacktfranklin@chromium.org
Change-Id: I723f8196904d62f3b024e662bfbbdb20742545d2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2424190
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
The original mechanism of enabling/disabling experiments has several
states:
- enabled (set to true in local storage)
- disabled (set to false in local storage, entry removed after refresh
- enabledTransiently (not interested, since it hides the checkbox)
- serverEnabled (not interested because it's from the server)
None of the states serve our needs, so a new state: enabledByDefault
has been added, which will turn on an experiment if user hasn't turned
it off explicitly before.
Also, since when the user turns off an experiment, the entry:
"experimentName": false
will only remain in the current session, and will be "cleaned up" when
DevTools refreshes, I've also updated the cleanup logic to avoid
cleaning up enabled-by-default experiments.
Backend CL to update tests: https://crrev.com/c/2418315
Bug: chromium:1047356
Change-Id: I32078b5c8bfd8de7bdd60578c84ba054cec3c05b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416525
Commit-Queue: Changhao Han <changhaohan@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Patrick Brosset <patrick.brosset@microsoft.com>
This reverts commit 862107080d.
Reason for revert: Chromium build issue fixed.
Original change's description:
> Revert "Reland "Remove support for remote modules""
>
> This reverts commit b3859e8d65.
>
> Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
>
> Original change's description:
> > Reland "Remove support for remote modules"
> >
> > This reverts commit d5044ddf05.
> >
> > Reason for revert: Fixed Chromium debug issue.
> >
> > Original change's description:
> > > Revert "Remove support for remote modules"
> > >
> > > This reverts commit 419c91eff6.
> > >
> > > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> > >
> > > Original change's description:
> > > > Remove support for remote modules
> > > >
> > > > LightHouse is currently broken in Canary, because of problems with
> > > > the appspot server. This isn't the first occurrence of this problem
> > > > and it becomes increasingly more difficult to figure out why the
> > > > server keeps on breaking. This is combined with a large infrastructure
> > > > cost of supporting remote modules and a confusing debugging experience
> > > > when working with it locally.
> > > >
> > > > The reason we had remote modules was the fact that these modules are
> > > > too large to be included in the Chromium bundle. In the last months,
> > > > we have made numerous remote modules bundled, by applying minifications
> > > > and optimizations to each module.
> > > >
> > > > The remaining remote module that we are currently shipping is LightHouse.
> > > > Since the remote appspot server is broken and unlikely to be fixed
> > > > anytime soon, now is the best time to finally resolve the remote
> > > > modules question.
> > > >
> > > > Therefore, we remove support for remote modules from the `module.json`
> > > > files and `Runtime.js`. Additionally, we update the build system
> > > > to properly generate the required files and load them via ES modules.
> > > >
> > > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > > more infrastructure related to scripts/remote modules, but given that
> > > > this CL is already quite large we are doing that in a follow-up CL.
> > > >
> > > > Follow-up action items for the LightHouse folks are to further decrease
> > > > the bundle size for LightHouse. Since we are now loading it via ES
> > > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > > well. This allows us to remove the copy of the SDK files, as well as
> > > > make use of proper ES exports, rather than the browserified requires.
> > > >
> > > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > > >
> > > > Fixed: 1128890
> > > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> > >
> > > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> > >
> > > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > > No-Presubmit: true
> > > No-Tree-Checks: true
> > > No-Try: true
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
> >
> > Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> > Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
>
> Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Change-Id: I8718e9d94c384a13fd18261f8f497d32418658fb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2421690
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit b3859e8d65.
Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
Original change's description:
> Reland "Remove support for remote modules"
>
> This reverts commit d5044ddf05.
>
> Reason for revert: Fixed Chromium debug issue.
>
> Original change's description:
> > Revert "Remove support for remote modules"
> >
> > This reverts commit 419c91eff6.
> >
> > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> >
> > Original change's description:
> > > Remove support for remote modules
> > >
> > > LightHouse is currently broken in Canary, because of problems with
> > > the appspot server. This isn't the first occurrence of this problem
> > > and it becomes increasingly more difficult to figure out why the
> > > server keeps on breaking. This is combined with a large infrastructure
> > > cost of supporting remote modules and a confusing debugging experience
> > > when working with it locally.
> > >
> > > The reason we had remote modules was the fact that these modules are
> > > too large to be included in the Chromium bundle. In the last months,
> > > we have made numerous remote modules bundled, by applying minifications
> > > and optimizations to each module.
> > >
> > > The remaining remote module that we are currently shipping is LightHouse.
> > > Since the remote appspot server is broken and unlikely to be fixed
> > > anytime soon, now is the best time to finally resolve the remote
> > > modules question.
> > >
> > > Therefore, we remove support for remote modules from the `module.json`
> > > files and `Runtime.js`. Additionally, we update the build system
> > > to properly generate the required files and load them via ES modules.
> > >
> > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > more infrastructure related to scripts/remote modules, but given that
> > > this CL is already quite large we are doing that in a follow-up CL.
> > >
> > > Follow-up action items for the LightHouse folks are to further decrease
> > > the bundle size for LightHouse. Since we are now loading it via ES
> > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > well. This allows us to remove the copy of the SDK files, as well as
> > > make use of proper ES exports, rather than the browserified requires.
> > >
> > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > >
> > > Fixed: 1128890
> > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> >
> > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> >
> > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
>
> Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
This reverts commit d5044ddf05.
Reason for revert: Fixed Chromium debug issue.
Original change's description:
> Revert "Remove support for remote modules"
>
> This reverts commit 419c91eff6.
>
> Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
>
> Original change's description:
> > Remove support for remote modules
> >
> > LightHouse is currently broken in Canary, because of problems with
> > the appspot server. This isn't the first occurrence of this problem
> > and it becomes increasingly more difficult to figure out why the
> > server keeps on breaking. This is combined with a large infrastructure
> > cost of supporting remote modules and a confusing debugging experience
> > when working with it locally.
> >
> > The reason we had remote modules was the fact that these modules are
> > too large to be included in the Chromium bundle. In the last months,
> > we have made numerous remote modules bundled, by applying minifications
> > and optimizations to each module.
> >
> > The remaining remote module that we are currently shipping is LightHouse.
> > Since the remote appspot server is broken and unlikely to be fixed
> > anytime soon, now is the best time to finally resolve the remote
> > modules question.
> >
> > Therefore, we remove support for remote modules from the `module.json`
> > files and `Runtime.js`. Additionally, we update the build system
> > to properly generate the required files and load them via ES modules.
> >
> > We will be able to perform subsequent cleanups in the Runtime to remove
> > more infrastructure related to scripts/remote modules, but given that
> > this CL is already quite large we are doing that in a follow-up CL.
> >
> > Follow-up action items for the LightHouse folks are to further decrease
> > the bundle size for LightHouse. Since we are now loading it via ES
> > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > well. This allows us to remove the copy of the SDK files, as well as
> > make use of proper ES exports, rather than the browserified requires.
> >
> > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> >
> > Fixed: 1128890
> > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
>
> Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit 419c91eff6.
Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
Original change's description:
> Remove support for remote modules
>
> LightHouse is currently broken in Canary, because of problems with
> the appspot server. This isn't the first occurrence of this problem
> and it becomes increasingly more difficult to figure out why the
> server keeps on breaking. This is combined with a large infrastructure
> cost of supporting remote modules and a confusing debugging experience
> when working with it locally.
>
> The reason we had remote modules was the fact that these modules are
> too large to be included in the Chromium bundle. In the last months,
> we have made numerous remote modules bundled, by applying minifications
> and optimizations to each module.
>
> The remaining remote module that we are currently shipping is LightHouse.
> Since the remote appspot server is broken and unlikely to be fixed
> anytime soon, now is the best time to finally resolve the remote
> modules question.
>
> Therefore, we remove support for remote modules from the `module.json`
> files and `Runtime.js`. Additionally, we update the build system
> to properly generate the required files and load them via ES modules.
>
> We will be able to perform subsequent cleanups in the Runtime to remove
> more infrastructure related to scripts/remote modules, but given that
> this CL is already quite large we are doing that in a follow-up CL.
>
> Follow-up action items for the LightHouse folks are to further decrease
> the bundle size for LightHouse. Since we are now loading it via ES
> modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> well. This allows us to remove the copy of the SDK files, as well as
> make use of proper ES exports, rather than the browserified requires.
>
> R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
>
> Fixed: 1128890
> Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
LightHouse is currently broken in Canary, because of problems with
the appspot server. This isn't the first occurrence of this problem
and it becomes increasingly more difficult to figure out why the
server keeps on breaking. This is combined with a large infrastructure
cost of supporting remote modules and a confusing debugging experience
when working with it locally.
The reason we had remote modules was the fact that these modules are
too large to be included in the Chromium bundle. In the last months,
we have made numerous remote modules bundled, by applying minifications
and optimizations to each module.
The remaining remote module that we are currently shipping is LightHouse.
Since the remote appspot server is broken and unlikely to be fixed
anytime soon, now is the best time to finally resolve the remote
modules question.
Therefore, we remove support for remote modules from the `module.json`
files and `Runtime.js`. Additionally, we update the build system
to properly generate the required files and load them via ES modules.
We will be able to perform subsequent cleanups in the Runtime to remove
more infrastructure related to scripts/remote modules, but given that
this CL is already quite large we are doing that in a follow-up CL.
Follow-up action items for the LightHouse folks are to further decrease
the bundle size for LightHouse. Since we are now loading it via ES
modules, we can now use ES imports in the `devtools-dt-bundle.js` as
well. This allows us to remove the copy of the SDK files, as well as
make use of proper ES exports, rather than the browserified requires.
R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
Fixed: 1128890
Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This changes `emulated_devices` to load from bundled, via the
`importScriptPathPrefix` in Runtime, rather than the remoteBase. We
need to load these images from the bundle, rather than remote, for
security and stability reasons.
For the build changes, we need to move the `_module.js` to non-remote,
have to update the GRD to include the files and copy the files to
the correct locations in the `resources/inspector/` and `gen/devtools/`.
All images are compressed with AVIF for the best compression rate, to
keep the impact on the Chromium binary size to a minimum. This CL
increases the bundle size of `resources.pak` by about 100Kb.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Fixed: 1095614
Change-Id: If1bdceeda8c00e9981dc229fd7c81022bb6ae6f9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2248183
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This refactors away the cachedResources from an object map
to a normal Map as defined in `Runtime.js`. The Map is used during
boot time by setting the relevant stylesheet contents, which is
included by `build_release_applications`. Moreover, it moves the
`*_module.js` files into the `modules` array rather than scripts.
This ensures that `*_module.js` files can use ES imports.
In a follow-up CL, we can do additional cleanup in the Runtime
to stop retrieving `resources` in `_loadResources`, as that should
no longer be possible. (In both debug and non-debug we build the
appropriate `_module.js` files)
R=aerotwist@chromium.org,aerotwist@chromium.org
Bug: 1058320
Change-Id: I89602b332360338f5914038f6cd505f75b531f8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2398829
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This rule disallows assigning a value in a return statement.
It also works in one-liner arrow functions.
For instance, a => a = 2 will trigger a warning.
This is to avoid cases where you actually meant to compare a to 2, not
assign the value 2 (maybe you wanted to return a boolean in a filter
callback).
These sorts of issues can easily pass review and cause weird problems
that are hard to track down later.
The rule is enabled in this CL, and all warnings are fixed with this CL.
More info about the rule: https://eslint.org/docs/rules/no-return-assign
Bug: 1093379
Change-Id: I38b98ea59ecaedc83a7f69073b17980808f9a3bf
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2242761
Reviewed-by: Patrick Brosset <patrick.brosset@microsoft.com>
Reviewed-by: Jose Leal <joselea@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Patrick Brosset <patrick.brosset@microsoft.com>
This CL adds the ability (hidden behind an experiment) for users to
select a set of shortcuts to use, the two options initially being the
default shortcuts and shortcuts that match those from VS Code. A new
`keybindSets` array is added to binding objects in module.jsons,
allowing shortcuts to be filtered on launch much like the existing
platform option. Also like platform, if the keybindSets array is
undefined for a shortcut then that shortcut will be considered common to
all keybindSets.
In general, I left keybindSets undefined for default DevTools shortcuts
that do not conflict with VS Code shortcuts so that they remain common
shortcuts. When both the DevTools and VS Code define the same shortcut,
I add both sets to keybindSets.
This should only affect users who have opted into the custom keyboard
shortcuts experiment. If a user with the experiment enabled selects VS
Code shortcuts and then turns the experiment off, ShortcutRegistry will
reset the shortcuts to the DevTools default on next launch.
Enumerating the differences between VS Code and the DevTools default
shortcuts uncovered some workflows that we'd like to add shortcuts for
that do not currently have actions in the DevTools, such as save as and
find/replace. I plan to add those in future CLs.
Due to problems with ListWidget's accessibility, I have to manually add
aria roles to the list and list items. This is a temporary state of
affairs until this tab is changed to use ListControl rather than
ListWidget for better accessibility. Since the ListWidget here contains
no editable items and is only marked as a list, there are no keyboard
navigation or focus management requirements to worry about yet.
I have put up a telemetry CL here so that we can evaluate the success of
the feature:
https://chromium-review.googlesource.com/c/chromium/src/+/2172132
Screenshots:
https://i.imgur.com/ka0VEyM.pnghttps://i.imgur.com/CG8hAro.png
Custom shortcuts design doc: https://docs.google.com/document/d/1oOPSWPxCHvMoBZ0Fw9jwFZt6gP4lrsrsl8DEAp-Hy7o/edit#
Bug: 174309
Change-Id: I0e3484eb2712c945121cc7b68e14a1a98f858bab
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2095859
Reviewed-by: John Emau <John.Emau@microsoft.com>
Reviewed-by: Songtao Xia <soxia@microsoft.com>
Commit-Queue: Jack Lynch <jalyn@microsoft.com>
This patch makes it so that all module.json files use the same
consistent indentation that matches .editorconfig and the rest
of the codebase. At the request of reviewers, one such file
(front_end/emulated_devices/module.json) has been excluded
from this patch. It will be reformatted in a separate CL.
Note that this patch does not “roll CodeMirror”, although a
pre-commit hook forces me to include that phrase in the commit
message because the module.json file in the relevant folder is
modified.
Bug: chromium:1070492
Change-Id: Ib31ed5232461e2f80bf05f31105fc919f6639b0a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2127007
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
front_end/Runtime.js was doing multiple things: it was instantiating
side-effecty descriptors and initializing applications, as well as
storing all state for the modules/extensions, etc...
To support proper ES Modules, we need to separate these. root/Runtime.js
contains simple classes that store the data and can be retrieved, as well
as some helper functions that will load the respective data.
The RuntimeInstantiator.js code includes the start functions used in the
entrypoints themselves. They will use an instance of the Runtime to
properly load the application.
Along the way, I also fixed various TypeScript errors, mostly around
incorrect or missing type definitions.
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: If3ddea9267813691b3faeb6ea4b0cf64edbde1f4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107523
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Tim van der Lippe
