Adding upstream version 115.7.0esr.upstream/115.7.0esr

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

2 files changed, 175 insertions, 0 deletions

diff --git a/devtools/docs/contributor/files/README.md b/devtools/docs/contributor/files/README.md
new file mode 100644
index 0000000000..8d85916b12
--- /dev/null
+++ b/devtools/docs/contributor/files/README.md
@@ -0,0 +1,12 @@
+# Directories Overview
+
+This page provides a very top level overview of what is on each directory in the DevTools source code:
+
+* `devtools/shared`: Code shared by both the client (front-end UI) and server. If we are using any third party libraries, or importing external repositories into our tree, those libraries generally live here (eg, `devtools/shared/jsbeautify`), assuming they are used by both client and server.
+  * `devtools/shared/client`: Code for the [Remote Debugging Protocol](../backend/protocol.md) (RDP) client. You may wonder why this is not in `devtools/client` below: it's mainly because tests in server also need access to the RDP client.
+  * `devtools/shared/locales`: Strings used in either the server only, or shared with both the client and server.
+* `devtools/server`: Code for the [RDP](../backend/protocol.md) server and transport layer.
+  * `devtools/server/actors`: [RDP Actors](../backend/protocol.md#actors). Note that if you're modifying actors, you may need to worry about [backwards compatibility](../backend/backward-compatibility.md) with older clients.
+* `devtools/client`: Code for the front-end side of our tools. In theory, each directory corresponds to a panel, but this is not always the case. This directory is only shipped with desktop Firefox, as opposed to other directories above, which are shipped with all Gecko products (Firefox for Android, etc.)
+  * `devtools/client/locales`: Strings used in the client front-end.
+  * `devtools/client/themes`: CSS and images used in the client front-end.
diff --git a/devtools/docs/contributor/files/adding-files.md b/devtools/docs/contributor/files/adding-files.md
new file mode 100644
index 0000000000..5d1fca4b1e
--- /dev/null
+++ b/devtools/docs/contributor/files/adding-files.md
@@ -0,0 +1,163 @@
+# Adding New Files - Various DevTools Resource Types
+
+This page lists the various DevTools resource types and how they can be created and loaded.
+
+## JavaScript Modules
+
+### Build Configuration
+
+JavaScript modules are installed by our build system using `moz.build` files. If you add a new JavaScript module, you'll need to update (or add) one of these files to make the build system aware of your new module. See the example below.
+
+A `moz.build` file must live in the same directory as the files to be installed. Don't list files from a subdirectory in a `moz.build` from a parent directory.
+
+Following these steps ensures that `require()` and `resource://` paths map directly to locations in the source tree, instead of being totally arbitrary.
+
+Example:
+
+* File: `/devtools/server/actors/layout.js`
+* In `/devtools/server/actors/moz.build`:
+
+```
+DevToolsModules(
+  'layout.js'
+)
+```
+
+### `require()`
+
+Most DevTools JS code is in the form of CommonJS modules that are loaded with `require()`.
+
+To `require()` a file, the module ID is exactly its source tree path.
+
+Example:
+
+* File: `/devtools/server/actors/layout.js`
+* Usage (prefer lazy in most cases):
+  * `loader.lazyRequireGetter(this, "layout", "devtools/server/actors/layout")`
+  * `require("devtools/server/actors/layout")`
+
+### `ChromeUtils.import()`
+
+Some older DevTools JS modules use the Gecko JavaScript code module format with the file extension `.jsm`. We are trying to move away from this format, so it's unlikely you would add a new one, but you might need to import an existing one in your code.
+
+These modules are loaded using `ChromeUtils.import()`. To `import()` a file, you provide a `resource://` URL, which is exactly the source tree path.
+
+In more detail:
+
+* `/devtools/client/<X>: resource://devtools/client/<X>`
+* `/devtools/server/<X>: resource://devtools/server/<X>`
+* `/devtools/shared/<X>: resource://devtools/shared/<X>`
+
+Example:
+
+* File: `/devtools/shared/loader/Loader.sys.mjs`
+* Usage:
+  * `const { loader } = ChromeUtils.importESModule("resource://devtools/shared/loader/Loader.sys.mjs")`
+
+Example:
+
+* File: `/toolkit/mozapps/extensions/AddonManager.jsm`
+* Usage (prefer lazy in most cases):
+  * `const lazy = {}; ChromeUtils.defineModuleGetter(lazy, "AddonManager", "resource://gre/modules/AddonManager.jsm")`
+  * `const { AddonManager } = ChromeUtils.import("resource://gre/modules/AddonManager.jsm")`
+
+## Chrome Content
+
+Much of the DevTools front-end / UI is currently loaded using `chrome://` URLs, which allow those files to have privileged access to platform internals.
+
+This is typically used to load XUL, HTML, and JS files in the UI.
+
+Note: "Chrome" here means "browser chrome", as in the UI, and bears no relation to "Chrome" as in the browser. We'd like to move away from this on DevTools and be more like regular web sites, but most tools are using `chrome://` URLs for now.
+
+### Packaging
+
+If you add a new file that should be loaded via a `chrome://` URL, you need to update a manifest file at `/devtools/client/jar.mn` so that it's packaged correctly.
+
+Please ensure that any new files are added so their entire source tree path is part of the URL. To do so, the `jar.mn` entry should look like:
+
+```
+content/<X> (<X>)
+```
+
+where `<X>` is the path to your file after removing the `/devtools/client/` prefix.
+
+Example:
+
+* File: `/devtools/client/webaudioeditor/models.js`
+* Entry: `content/webaudioeditor/models.js (webaudioeditor/models.js)`
+
+### Usage
+
+Chrome content URLs almost match their source tree path, with one difference: the segment `client` is replaced by `content`. This is a requirement of the `chrome://` protocol handler.
+
+Example:
+
+* File: `/devtools/client/webaudioeditor/models.js`
+Usage: `chrome://devtools/content/webaudioeditor/models.js`
+
+For files within a single tool, consider relative URLs. They're shorter!
+
+## Chrome Themes
+
+Similar to the chrome content section above, we also use chrome themes (or `skin` URLs) in the DevTools UI. These are typically used to load CSS and images.
+
+### Packaging
+
+If you add a new file that should be loaded via `chrome://` (such as a new CSS file for a tool UI), you need to update a manifest file at `/devtools/client/jar.mn` so that it's packaged correctly.
+
+Please ensure that any new files are added so their entire source tree path is part of the URL. To do so, the `jar.mn` entry should look like:
+
+```
+skin/<X> (themes/<X>)
+```
+
+where `<X>` is the path to your file after removing the `/devtools/client/themes/` prefix.
+
+Example:
+
+* File: `/devtools/client/themes/images/add.svg`
+* Entry: `skin/images/add.svg (themes/images/add.svg)`
+
+### Usage
+
+Chrome theme URLs almost match their source tree path, with one difference: the segment `client/themes` is replaced by `skin`. This is a requirement of the `chrome://` protocol handler.
+
+Example:
+
+* File: `/devtools/client/themes/images/add.svg`
+* Usage: `chrome://devtools/skin/images/add.svg`
+
+## Localization (l10n)
+
+Similar to the other chrome sections above, we also use `locale` URLs in the DevTools UI to load localized strings. This section applies to `*.dtd` (for use as entities within XUL / XHTML files) and `*.properties` (for use via runtime APIs) files.
+
+We currently have two sets of localized files:
+
+* `devtools/client/locales`: Strings used in the DevTools client (front-end UI)
+* `devtools/shared/locales`: Strings used in either the DevTools server only, or shared with both the client and server
+
+### Packaging
+
+If you add a new l10n file (such as a new `*.dtd` or `*.properties` file), there should not be any additional packaging steps to perform, assuming the new file is placed in either of the 2 directories mentioned above. Each one contains a `jar.mn` which uses wildcards to package all files in the directory by default.
+
+### Usage
+
+Locale URLs differ somewhat based on whether they are in `client` or `shared`. While we would have preferred them to match the source tree path, the requirements of the `chrome://` protocol don't make that easy to do.
+
+Example:
+
+* File: `/devtools/client/locales/en-US/debugger.dtd`
+* Usage: `chrome://devtools/locale/debugger.dtd`
+
+Example:
+
+* File: `/devtools/shared/locales/en-US/screenshot.properties`
+* Usage: `chrome://devtools-shared/locale/screenshot.properties`
+
+### Guidelines
+
+Localization files should follow a set of guidelines aimed at making it easier for people to translate the labels in these files in many languages.
+
+[Read best practices for developers](https://mozilla-l10n.github.io/documentation/localization/dev_best_practices.html).
+
+In particular, it's important to write self-explanatory comments for new keys, deleting unused keys, changing the key name when changing the meaning of a string, and more. So make sure you read through these guidelines should you have to modify a localization file in your patch.