In order to allow for localizing at extension registration with the new JavaScript based system, the localization calls done at processing on view extensions coming from module.json files were moved inside the ProvidedView class definition and right after the extensions are passed by the Runtime (before they are processed as views). This way, view extensions coming from the legacy and the new system are localized exactly once.
Bug: 1134103
Change-Id: I689f2f60bd662ecd63b4a361a61db4433c03b25b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2519818
Commit-Queue: Andres Olivares <andoli@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
While working on the linear memory inspector component
(https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2501301)
we discovered that both snippets and quick_open were side-effect
instantiating instances during module loading. This caused issues
when trying to write isolated unittests for other components, if
they were (transitively) importing these modules.
To resolve these issues, we defer creation to the appropriate time.
In the case of CommandMenu, this was a small refactoring to use
the instance-singleton-pattern we have been using throughout the
codebase.
For Snippets, it was less obvious. In the end, we realized that
the singleton instances that snippets/ was relying on were constructed
in `Main.MainImpl.MainImpl._createAppUI`. More specifically,
the instantiation of `self.Persistence.isolatedFileSystemManager`
right at the top of `_createAppUI` was implicitly required for
snippets/.
This wasn't a problem when loading DevTools, as we lazy-load snippets/
after we instantiate `MainImpl`. Hence, the singletons were in place
and the code would correctly function. However, that assumption is
invalid when loading `snippets/` in isolation, which was the case
when writing the unit test.
The same treatment was necessary for `Snippets.project`, which has
been moved to a lazily-computed function.
R=aerotwist@chromium.org,jacktfranklin@chromium.org,kimanh@chromium.org
Fixed: 1143170
Change-Id: I28d3bbbc428f0316ca89453f98331b7479711c87
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2503953
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
QuickOpen is a highly-useful UI affordance for the DevTools. However,
the actual implementation introduces some problems with reusability;
the QuickOpen tool is a global DevTools singleton that coalesces
multiple "Providers" across DevTools to handle activities like Go To
Line, Open document, or Invoke Command. Because it is a singleton, a
developer who wanted to leverage that input modality would need to drop
to the FilteredListWidget, which is tightly coupled to the QuickOpen
implementation and also has a non-obvious implementation pattern (one
would need to implement a Provider, and there is no straightforward way
to observe when the user cancels out of it).
This change borrows a simplified version of the VS Code QuickPick and
QuickInput APIs. With this, a DevTools developer can write a single
line, using an awaitable, so that the meaning and purpose of the input
collection is straightforward:
const text = await QuickInput.show({
prompt: 'Please enter some information.',
value: 'A default value',
valueSelection: [0, 15],
});
// text will contain the entered value, or undefined
QuickPick requires a few more lines to implement, but provides a
similarly easy-to-use interface:
const demoMenu1 = [
{
label: 'Item 1',
},
{
label: 'Item 2',
},
{
label: 'Item 3',
}
];
const choice = await QuickPick.show(demoMenu1, {
placeHolder: 'Choose from these options:'
});
// choice contains one of the objects from demoMenu1, or undefined
The explainer can be found here:
https://docs.google.com/document/d/1EibIlPCeH-672wncOScGoMbSs0EzNY4SSaqJng-5-S4/edit#
... and GIFs of these in action can be found here:
https://imgur.com/a/GCfpHQ3
Bug: 1103402
Change-Id: I1ca7c7c87243553ff45d00369ce8996c2914be93
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2288530
Reviewed-by: Brandon Goddard <brgoddar@microsoft.com>
Commit-Queue: Robert Paveza <Rob.Paveza@microsoft.com>
This patch replaces unwelcoming language with better terms.
Generally, the following replacements are made:
- whitelist → allowlist
- blacklist → blocklist
However, in some cases where “whitelist” was used as part of the
function name (e.g. `isWhitelistedProperty`) it felt more natural to
simplify the name (i.e. `isAllowedProperty` instead of the slightly
awkward `isAllowlistedProperty`).
This patch does not change third_party dependencies nor Lighthouse.
It also leaves `setWhitelistedShortcuts` for now, since renaming that
requires changes in Blink.
Change-Id: I56712d15b32b6a4259ccb333de6edd5fc62ee03f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238229
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
This CL adjusts entrypoints for Settings.
1) Adds a Settings Gear icon to the top-level toolbar
2) Moves Settings ... menu entry to More tools submenu
https://i.imgur.com/9WS6EGy.png
This CL also includes telemetry for Settings,
so we can better evaluate how users are finding Settings,
and which Settings tabs are most popular.
1) Record a User Action for opening Settings
- Reveal Settings via Gear icon
- Reveal Settings via Top Menu -> More tools -> Settings
OR via Top Menu -> Shortcuts
- Reveal Settings via Command menu
Remark: The keyboard shortcut F1 / Shift+? to reveal Settings
does not record an action here; keyboard shortcut telemetry for the
settings.show action is already taken care of.
2) Report Panel Open action for each Settings tab
- On reveal: should report exactly the panel opened once
- On switch tabs: should report exactly the panel switched to once
The corresponding Chrome CL to add the new enums is here.
https://chromium-review.googlesource.com/c/chromium/src/+/2055359
In order to have the Settings screen record Panel Open actions
reliably, a new TabInvoked event was added to TabbedPane which is
triggered by all tab selections, both programmatic and user invoked.
The existing TabSelected event only triggers on tab changes.
Using TabSelected prevent the Settings screen from reporting panel open
events when closed and re-opened to the same tab.
One criteria for determining whether to report a panel open is that
the tab is invoked by a user (userGesture) and not programmatically.
For user invokable items in context menu and the Command menu,
this userGesture argument is now set to `true` by default,
as both must have been invoked by a user.
Bug: 1050855
Change-Id: Id2e6e5f995bf2e6d419a3144eeec3e6af2bf208b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2049183
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
Reviewed-by: Jack Lynch <jalyn@microsoft.com>
Commit-Queue: Brian Cui <brcui@microsoft.com>
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>
Introduce a new namespace "Root" to be able to disambiguate between
Runtime the namespace and Runtime the object.
roll CodeMirror
The above line is necessary to fix the presubmit, which complains
about CodeMirror changes. This is only updating a type reference.
Bug: 1006759
Change-Id: I04941d9f18649701060e3035f7eeb2ef3abb51e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1829708
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#701257}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 17cc008cf6ad28c6e8c07c638a1b380ca30e7f79
The Chromium/Google style guides does not enforce curly braces for
single-line if-statements, but does strongly recommend doing so. Adding
braces will improve code readability, by visually separating code
blocks. This will also prevent issues where accidental additions are
pushed to the "else"-clause instead of in the if-block.
This CL also updates the presubmit `eslint` to run the fix with the
correct configuration. It will now fix all issues it can fix.
Change-Id: I4b616f21a99393f168dec743c0bcbdc7f5db04a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1821526
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jeff Fisher <jeffish@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#701070}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7e0bdbe2d7f9fc2386bfaefda3cc29c66ccc18f9
The tags in Module.json are not localized. This change localize them,
so when users type the word in command menu with languages other than
English, the results can show up correctly.
Two scripts edited (check_localized_strings.js, CommandMenu.js).
Grdp changes are generated automatically, with manually added descriptions.
Bug: 941561
Change-Id: I3dc1f8f8b72e21748f5fa84c1c60b9597aa0414a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1809673
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mandy Chen <mandy.chen@microsoft.com>
Commit-Queue: Christy Chen <chrche@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#698223}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b75a4b07ffd26a61fef0344123701241bb75002c
Tim van der Lippe
