chrome-devtools-frontend 1.0.1516909 → 1.0.1519267

package/config/owner/COMMON_OWNERS

@@ -16,15 +16,15 @@ kprokopenko@chromium.org
 leese@chromium.org
 mathias@chromium.org
 nancyly@chromium.org
-nechaev@chromium.org
 nharshunova@chromium.org
+nroscino@chromium.org
 nvitkov@chromium.org
 paulirish@chromium.org
 petermueller@chromium.org
 pfaffe@chromium.org
 piotrpaulski@chromium.org
 sadym@chromium.org
-samiyac@chromium.org
+samiyac@google.com
 szuend@chromium.org
 victorporof@chromium.org
 wolfi@chromium.org

package/docs/checklist/README.md

@@ -46,7 +46,7 @@ in the Elements tab looks alright and works as expected (typically, this require
 
 Verify that the new properties show up in the DevTools Console autocomplete functionality (typically, this requires no additional implementation effort).
 To enable argument hints for new or changed parameterized functions, run
-```
+```bash
 devtools-frontend/src/scripts/deps/roll_deps.py
 ```
 to re-generate `devtools-frontend/src/front_end/models/javascript\_metadata/NativeFunctions.js` ([Example CL](http://crrev.com/c/3432787)).
@@ -88,7 +88,7 @@ Example for `:target`: [Chromium back-end CL](https://chromium-review.googlesour
 
 To recognize new CSS properties/values in the DevTools Styles panel’s autocomplete functionality, roll
 [Chromium’s `css_properties.json5`](https://source.chromium.org/chromium/chromium/src/+/main:third\_party/blink/renderer/core/css/css_properties.json5;drc=be2c473625b9c28a4ff6735547cb0c1b6743f4ae) into the `devtools-frontend` repository by running
-```
+```bash
 devtools-frontend/src/scripts/deps/roll_deps.py
 ```
 see this [example CL](https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2972583).

package/docs/checklist/javascript.md

@@ -306,7 +306,7 @@ NLFs that contain control flow (e.g branches, loops, etc.).
 
 Run `d8` with `--lcov` and check whether the produced coverage information is correct. E.g. like this:
 
-```
+```bash
 ./d8 --lcov=cov.info test.js
 genhtml cov.info -o coverage
 ```

package/docs/contributing/README.md

@@ -187,7 +187,7 @@ Once you’re done preparing your patch, it’s time to upload your changes.
 
 After that, you are ready to start the patch upload:
 
-```
+```bash
 # upload your patch to codereview…
 git cl upload
 ```

package/docs/contributing/settings-experiments-features.md

@@ -49,13 +49,13 @@ const base::FeatureParam<double> kDevToolsNewFeatureDoubleParam{
 
 Start Chrome via command line including flags:
 
-```
+```bash
 out/Default/chrome --enable-features=DevToolsNewFeature
 ```
 
 You can even pass additional feature parameters:
 
-```
+```bash
 out/Default/chrome --enable-features="DevToolsNewFeature:string_param/foo/double_param/0.5"
 ```
 
@@ -113,7 +113,8 @@ In DevTools, you need to register the experiment. This is done in
 Root.Runtime.experiments.register(
   'yourExperimentNameHere',
   'User facing short description of experiment here',
-  false);
+  false,
+);
 ```
 
 The first argument is the experiment's label, and **this must match the label
@@ -134,9 +135,9 @@ documentation and a way to provide feedback:
 Root.Runtime.experiments.register(
   'jsProfilerTemporarilyEnable',
   'Enable JavaScript Profiler temporarily',
-   /* unstable= */ false,
-   /* documentation */ 'https://goo.gle/js-profiler-deprecation',
-   /* feedback */ 'https://crbug.com/1354548'
+  /* unstable= */ false,
+  /* documentation */ 'https://goo.gle/js-profiler-deprecation',
+  /* feedback */ 'https://crbug.com/1354548',
 );
 ```
 
@@ -149,7 +150,7 @@ Once the experiment is registered, you can check if it is enabled and use this
 to run certain code blocks conditionally:
 
 ```ts
-if(Root.Runtime.experiments.isEnabled('yourExperimentNameHere')) {
-   // Experiment code here
+if (Root.Runtime.experiments.isEnabled('yourExperimentNameHere')) {
+  // Experiment code here
 }
 ```

package/docs/cookbook/devtools_on_devtools.md

@@ -43,7 +43,7 @@ set up your Chrome or Chromium instance for earlier versions of M-136 and M-135.
 
 Then in your `devtools-frontend` checkout, use
 
-```
+```bash
 ./third_party/chrome/chrome-linux/chrome \
    --disable-infobars \
    --custom-devtools-frontend=file://$(realpath out/Default/gen/front_end)
@@ -51,7 +51,7 @@ Then in your `devtools-frontend` checkout, use
 
 on Linux or
 
-```
+```bash
 ./third_party/chrome/chrome-mac/Google\ Chrome\ for\ Testing.app/Contents/MacOS/Google\ Chrome\ for\ Testing \
   --disable-infobars \
   --disable-features=MediaRouter \

package/docs/cookbook/localization.md

@@ -15,7 +15,7 @@ Before proceeding, make sure you know the different
 
 Code example:
 
-```js
+```ts
 import * as i18n from '../i18n/i18n.js';
 
 // at the top of example.js file, after import statements
@@ -57,7 +57,7 @@ console.log(message2);
     to it. If there isn't `UIStrings = {}` in the file, create one and add your
     string, also register the new UIStrings into the `en-US.json` by adding:
 
-    ```js
+    ```ts
     // Filename should be relative to front_end folder
     const str_ = i18n.i18n.registerUIStrings('<filename>', UIStrings);
     const i18nString = i18n.i18n.getLocalizedString.bind(undefined, str_);
@@ -145,7 +145,7 @@ The basic API to make a string (with or without placeholder) localizable. The
 first argument is the string reference in `UIStrings` The second argument is an
 object for placeholders (if any)
 
-```js
+```ts
 // at the top of example.js file, after import statements
 
 const UIStrings = {
@@ -172,7 +172,7 @@ locale, which are not available until after DevTools has finished starting up.
 Calls to `i18nString` in the module scope will therefore fail when the module is
 imported.
 
-```js
+```ts
 // Fails because i18nString runs at module-import time.
 Common.Settings.registerSettingExtension({
   category: Common.Settings.SettingCategory.CONSOLE,
@@ -188,7 +188,7 @@ function notTopLevel() {
 closure that returns a `LocalizedString`. It can be used in top-level calls;
 just make sure use-sites know it's a function now.
 
-```js
+```ts
 // Works because i18nLazyString defers the loading of the translated string until later.
 Common.Settings.registerSettingExtension({
   category: Common.Settings.SettingCategory.CONSOLE,
@@ -207,7 +207,7 @@ This call returns a **span element**, not a string. It is used when you want to
 construct a DOM element with a localizable string, or localizable content that
 contains some other DOM element.
 
-```js
+```ts
 // Create the string in UIString
 /**
 *@description Message in Coverage View of the Coverage tab
@@ -228,7 +228,7 @@ This call is a named cast. Use it in places where a localized string is expected
 but the term you want to use does not require translation. Instead of locking
 the whole phrase or using a placeholder-only phrase, use `lockedString`.
 
-```js
+```ts
 someFunctionRequiringALocalizedString(i18n.i18n.lockedString('HTTP'));
 ```
 
@@ -240,7 +240,7 @@ languages!
 
 **Good description**:
 
-```js
+```ts
 const UIStrings = {
   /**
    * @description Tooltip text that appears when hovering over the 'Focusable' attribute name under the Computed Properties section in the Accessibility pane of the Elements pane.
@@ -251,7 +251,7 @@ const UIStrings = {
 
 **Bad description**:
 
-```js
+```ts
 const UIStrings = {
   /**
    * @description Elements pane 'Focusable' tooltip.
@@ -289,7 +289,7 @@ const UIStrings = {
 Any text within the backticks will not be translated. For example, if the
 'robots.txt' in string 'Requesting for robots.txt …' should not be translated:
 
-```js
+```ts
 // in example.js file
 
 import * as i18n from '../i18n/i18n.js';

package/docs/devtools-protocol.md

@@ -73,9 +73,9 @@ Open the file
 `third_party/blink/renderer/core/inspector/inspector_protocol_config.json` and
 under `protocol.options`, add your new domain:
 
-```
+```json
 {
-    "domain": "YourNewDomain"
+  "domain": "YourNewDomain"
 }
 ```
 
@@ -85,7 +85,7 @@ Build chromium as you normally would.
 #### 1.6- See the newly generated protocol C++ files
 Your new domain files should be generated in this folder:
 
-```
+```bash
 src/out/Default/gen/third_party/blink/renderer/core/inspector/protocol/your_new_domain.cc
 src/out/Default/gen/third_party/blink/renderer/core/inspector/protocol/your_new_domain.h
 ```
@@ -94,7 +94,7 @@ src/out/Default/gen/third_party/blink/renderer/core/inspector/protocol/your_new_
 
 Open the file `devtools-frontend/front_end/core/protocol_client/InspectorBackend.ts` and add a new method to expose your Agent.
 
-```
+```ts
 youNewDomainAgent(): ProtocolProxyApi.YourNewAgentApi {
     return this.getAgent('YourNewAgent');
 }
@@ -112,13 +112,14 @@ outputs = [
 ...
 "inspector/protocol/your_new_domain.cc",
 "inspector/protocol/your_new_domain.h",
+]
 ```
 
 ### 2- Sync the browser_protocol files and generate the protocol resources
 As mentioned before, there are many browser_protocol files. To synchronize the
 modifications, run this command from your Chrome DevTools repository:
 
-```
+```bash
 scripts/deps/roll_deps.py ~/chromium/src .
 ```
 
@@ -132,7 +133,7 @@ Chrome DevTools repository.
 The Agent class should inherit the newly created protocol
 `protocol::YourNewDomainAgent::Metainfo`
 
-```
+```cpp
 class MODULES_EXPORT YourNewDomainAgent final : public InspectorBaseAgent<protocol::YourNewDomainAgent::Metainfo> {
 ```
 
@@ -141,7 +142,7 @@ The Agent must be registered with the Session. To do so, go to the file
 `third_party/blink/renderer/modules/modules_initializer.cc` and append it to the
  session in this method:
 
-```
+```cpp
 void ModulesInitializer::InitInspectorAgentSession {
 …
 session->CreateAndAppend<YourNewAgent>...
@@ -151,7 +152,7 @@ session->CreateAndAppend<YourNewAgent>...
 In the TypeScript class, your agent can now be accessible directly from the
 target. With the target, you can simply access your agent like this:
 
-```
+```ts
 initialize(target: SDK.Target.Target) {
     target.yourNewDomainAgent();
 }

package/docs/ecosystem/automatic_workspace_folders.md

@@ -54,7 +54,7 @@ workspace folders, it has to contain a `workspace` object with two properties:
 
 An example `com.chrome.devtools.json` would look like this:
 
-```
+```json
 {
   "workspace": {
     "root": "/Users/foobar/Projects/my-awesome-web-project",
@@ -81,7 +81,7 @@ turn on two feature flags in `about:flags`:
 Instead of enabling the feature via `about:flags`, you can instead also enable
 them from the command line:
 
-```
+```bash
 google-chrome-canary --enable-features=DevToolsWellKnown,DevToolsAutomaticFileSystems
 ```
 
@@ -99,7 +99,7 @@ need to do is to create a `.well-known/appspecific` folder and place a
 and you're directly serving the artifacts for your project from its source
 directory in `/Users/foo/bar`, then you could can accomplish the setup via:
 
-```
+```bash
 cd /Users/foo/bar
 mkdir -p .well-known/appspecific
 echo "{\"workspace\":{\"root\":\"${PWD}\",\"uuid\":\"`npx --package uuid uuid v4`\"}}" > .well-known/appspecific/com.chrome.devtools.json

package/docs/get_the_code.md

@@ -59,7 +59,6 @@ gn gen out/fast-build --args="devtools_skip_typecheck=true devtools_bundle=false
 and use `npm run build -- -t fast-build` to build this target (you can of course
 also just change the `Default` target to skip bundling and type checking).
 
-
 ### Rebuilding automatically
 
 You can use
@@ -176,7 +175,6 @@ npm start -- --verbose
 to enable verbose logging, which among other things, also prints all output from Chrome to the terminal, which is
 otherwise suppressed.
 
-
 ##### Controlling the feature set
 
 By default `npm start` will enable a bunch of experimental features (related to DevTools) that are considered ready for teamfood.