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>
Currently, ShortcutRegistry allows multiple shortcuts to be stored
within the same binding in a module.json, e.g. `"shortcut": "F8
Ctrl+\\"` creates two shortcuts, one on F8 and another on Ctrl+\. When
multi-keypress shortcuts/chords are added in the future, they'll use the
same format such that the above example would be interpreted as a single
shortcut bound to the F8 Ctrl+\ sequence. In order to allow that, it's
necessary to split up all of the existing shortcuts that are stored in
space-delimited strings so that they'll continue to function as
expected. This CL also updates the module.schema.json to disallow spaces
in shortcuts, a restriction that will be removed once multi-keypress
shortcuts are implemented.
Custom keyboard shortcuts design doc: https://docs.google.com/document/d/1oOPSWPxCHvMoBZ0Fw9jwFZt6gP4lrsrsl8DEAp-Hy7o/edit#heading=h.2xpjzz3fl1ju
Bug: 174309
Change-Id: I853f9918ad2892b2f4c4f3aec53013d7a6455f67
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2123807
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
Reviewed-by: Vidal Diazleal <vidorteg@microsoft.com>
Commit-Queue: Jack Lynch <jalyn@microsoft.com>
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>
Tim van der Lippe
