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>
Retrieving the {uiLocation} of a LiveLocation can involve source
mapping (via rawLocationToUILocation). As source mapping will be
async in the future we have to properly await {uiLocation} in these
LiveLocation update delegates.
Note that support for asynchronous LiveLocation updates has already
landed.
Bug: chromium:1032016
Change-Id: I81be755581b6347c8d510de3216503e32481e470
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2077667
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
This CL changes references to self.Bindings.cssWorkspaceBinding (the
globalinstance of Bindings.CSSWorkspaceBinding.CSSWorkspaceBinding) over
to Bindings.CSSWorkspaceBinding.CSSWorkspaceBinding.instance(). To keep
both TypeScript and Closure happy we must make a method on the
CSSWorkspaceBinding class itself, since it only allows private
constructors to be accessed by static methods on the class.
Bug: 1058320
Change-Id: Ic42d2b76e5bcec38029827dce14e3bf06ceaf89a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107520
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
This CL changes references to self.Bindings.resourceMapping (the global
instance of Bindings.ResourceMapping.ResourceMapping) over to
Bindings.ResourceMapping.ResourceMapping.instance(). To keep both
TypeScript and Closure happy we must make a method on the
ResourceMapping class itself, since it only allows private constructors
to be accessed by static methods on the class.
Bug: 1058320
Change-Id: I9c90bd5aa449bf0bfdea48c7e374d8ddccc58747
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107221
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
The runtime was throwing errors because `Snippets.SnippetsQuickOpen` did
not exist. The culprit is that the export statement still included a
`default class` rather than a `class`.
Also added an e2e-test that goes through the workflow of creating a
snippet and then verifying that the command menu shows these snippets
in its autocompletion.
R=aerotwist@chromium.org
Bug: 1060565
Change-Id: I9bb9d4ed34e5fda25cdd796a6a1e4c8a61f89958
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107222
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This post-processes all JavaScript files with the Istanbul instrumenter.
The files in question are the output files from TypeScript, which means
that Istanbul operates on the TypeScript sourcemaps. As such, the coverage
report will have the correct lines.
For an unknown reason, Istanbul still adds empty files to the coverage report,
in the `out/Default/gen` directory. Since normal files are always loaded,
we ignore files with no coverage. It would be great to later figure out why
that is happening, but for now we are happy with skipping them.
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1061125
Change-Id: I754e8b9f46dd2fdb167eda6e64927c94b88ff676
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107218
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This CL changes references to self.Bindings.networkProjectManager (the
global instance of Bindings.NetworkProject.NetworkProjectManager) over
to Bindings.NetworkProject.NetworkProjectManager.instance(). To keep
both TypeScript and Closure happy we must make a method on the
NetworkProjectManager class itself, since it only allows private
constructors to be accessed by static methods on the class.
Bug: 1058320
Change-Id: I8adadca42dc2002d819dc42021bbaa6d80755a5a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107219
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL implements asyncified LiveLocation updates. As the called
update delegates might not be re-entrant, LiveLocation.update implements
simple scheduling using promises.
Please note that no update delegate does anything asynchronous yet. This
CL has to land first before we can properly await {uiLocations} and
source mapping in LiveLocation update delegates.
Bug: chromium:1032016
Change-Id: Id38e0db794859c54b253e804841e6693b9d4800e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2077662
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
This CL is part of the asynchronous source mapping effort.
LiveLocation update handlers need to be asynchronous in the future
as those update handlers are users of source mapping. To enable
asynchronous LiveLocation update handlers, we need to make triggering
LiveLocation updates asynchronous. This also includes LiveLocation
creation, as immediately after creation an update is scheduled.
Note that most of this CL is dedicated to housekeeping. Tests need to
be able to wait for all LiveLocation changes to settle. To this end,
we keep track of all promises that either represent a new LiveLocation
or an update and expose them to a test helper.
Test runners and web tests were already updated to use this live
location helper, but until now it was a no-op.
Bug: chromium:1032016
Change-Id: I13365c92ba667906f9836c58886abe9b9e637a6f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2074764
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This CL changes references to self.Common.settings (the global
instance of SDK.Common.Settings) over to
Common.Settings.Settings.instance(). To keep both TypeScript and
Closure happy we must make a method on the Settings class itself,
since it only allows private constructors to be accessed by static
methods on the class.
Bug: 1058320
Change-Id: I04afc8caf64acf29cdda13ef03ad05cfff4786a1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2091450
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL fixes an issue where focus being on a checkbox in the event
listener breakpoints pane prevents keydown events from being handled by
its parent treeElement, forcing the user to shift-tab to focus the tree
element and navigate the breakpoints tree. Since checkboxes are input
elements, UIUtils.isEditing() returns true if one is focused (preventing
treeElement._treeKeyDown from handling it). To keep the fix simple, I'm
just adding focus listeners to the checkboxes that focus their
treeElements. Pressing space on a treeElement toggles its checkbox, so
all functionality that you would have from focusing a checkbox is
preserved.
Screencasts from the bug: https://drive.google.com/drive/folders/11_47xiS-aMNXXQwvMP-9Or4Dr_QaZFdi?usp=sharing
Bug: 1058338
Change-Id: I4bbcbae29eb0b5dcdaf677388eca2f33be8ceab5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2088117
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
Reviewed-by: Brian Cui <brcui@microsoft.com>
Commit-Queue: Jack Lynch <jalyn@microsoft.com>
These files were used in the pre-ES module module era, to instruct
editors like VS Code to resolve symbols. However, since we are in ES
modules land we explicitly *don't* want this resolution. By removing
suport for jsconfig, the editor will now warn before hand on un-imported
symbols. This should reduce the risk of accidentally using the global
symbol rather than the import.
After this change, there will be numerous `jsconfig.json` in the
repository. You are recommended to `git add . && git reset --hard` to
remove these from your local checkout.
Most files will now see a lot of red squiggles with errors, which is to
be expected, as TypeScript does not understand many of the globals. I
have declared `ls` in the globals to at least suppress these, as well as
fix the definition of UIString. These seem to be the most prominent.
All other usages will still need fixing before the files in question can
be typescriptified. However, we do hope that with this change, it is
more difficult to check in new code that is not compliant with
TypeScript already.
Bug: 1006759
Change-Id: I6591e73d66c845a2160b843b627c1adcb1389c24
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2098602
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
This will result in nicer assertion messages with Karma.
Before:
HeadlessChrome 82.0.4071 (Mac OS X 10.15.3) Color defaults RGBA value to 0 if the RGBA initializing value given was negative FAILED
AssertionError: RGBA array was not set correctly: expected [ 0, 0.5, 0.5, 0.5 ] to deeply equal [ 0, 0.5, 0.5, 0.6 ]
at Context.<anonymous> (test/unittests/front_end/common/Color_test.js:15:16)
After:
HeadlessChrome 82.0.4071 (Mac OS X 10.15.3) Color defaults RGBA value to 0 if the RGBA initializing value given was negative FAILED
AssertionError: RGBA array was not set correctly: expected [ 0, 0.5, 0.5, 0.5 ] to deeply equal [ 0, 0.5, 0.5, 0.7 ]
at Context.<anonymous> (test/unittests/front_end/common/Color_test.ts:19:12 <- out/Default/gen/test/unittests/front_end/common/Color_test.js:15:16)
R=aerotwist@chromium.org,jacktfranklin@chromium.org
DISABLE_THIRD_PARTY_CHECK=Update to TypeScript
Bug: 1061125
Change-Id: Ia689b2a0a6e6f7d221d29786727700be02e8649b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2105437
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
devtools-ci-autoroll-builder