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.png https://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>
DevTools Scripts
Development workflow scripts
These are scripts that can be useful to run independently as you're working on Chrome DevTools front-end.
The newer scripts such as for testing and hosted mode are written in Node.js, which has become the standard toolchain for web apps. The older scripts such as building (e.g. bundling and minifying) are written in Python, which has first-class support in Chromium's infrastructure.
Overview
Folders
- build - Python package for generating DevTools debug and release mode
- chrome_debug_launcher - automagically finds Chrome Canary and launches it with debugging flags (e.g. remote debugging port)
- closure - see section on Closure Compiler below
- gulp - experimental build process written in node.js & gulp to remove the dependency on Chromium-specific build tools (i.e. gn and ninja)
- hosted_mode - run DevTools on a localhost development server
- jsdoc_validator - enforces the use of Closure type annotations
Python Scripts
- compile_frontend.py - runs closure compiler to do static type analysis
- Note: the compiled outputs are not actually used to run DevTools
- lint_javascript.py - run eslint
- optimize_svg_images.py - manually run when changing svg images
Node.js scripts
The easiest way to run the node.js scripts is to use npm run which displays all the commands. For more information on the specific npm run commands, take a look at the primary devtools front-end readme (../readme.md).
Closure
DevTools manually rolls the closure compiler to ./closure. If you manually roll closure compiler, you will need to re-generate the closure_runner (in ./closure) and jsdoc_validator custom jars using the python scripts in their respective directory.