Bug 1689954 - [devtools] Use sphinx directives instead of hints in documentation. . DONTBUILD

Differential Revision: https://phabricator.services.mozilla.com/D103769
This commit is contained in:
Nicolas Chevobbe 2021-02-02 13:27:43 +00:00
parent d5c7f81a2c
commit 7430a7d93b
2 changed files with 16 additions and 20 deletions

View File

@ -2,13 +2,11 @@
In multi-process environments, most devtools actors are created and initialized in the child content process, to be able to access the resources they are exposing to the toolbox. But sometimes, these actors need to access things in the parent process too. Here's why and how.
{% hint style="danger" %}
This documentation page is **deprecated**. `setupInParent` relies on the message manager which is being deprecated. Furthermore, communications between parent and content processes should be avoided for security reasons. If possible, the client should be responsible for calling actors both on the parent and content process.
This page will be removed when all actors relying on this API are removed.
{% endhint %}
```warning::
| This documentation page is **deprecated**. setupInParent relies on the message manager which is being deprecated. Furthermore, communications between parent and content processes should be avoided for security reasons. If possible, the client should be responsible for calling actors both on the parent and content process.
|
| This page will be removed when all actors relying on this API are removed.
```
## Use case and examples

View File

@ -3,19 +3,17 @@
See [Performance tests (DAMP)](performance-tests.md) for an overall description of our performance tests.
Here, we will describe how to write a new test and register it to run in DAMP.
{% hint style="tip" %}
**Reuse existing tests if possible!**
If a `custom` page already exists for the tool you are testing, try to modify the existing `custom` test rather than adding a new individual test.
New individual tests run separately, in new tabs, and make DAMP slower than just modifying existing tests. Complexifying `custom` test pages should also help cover more scenarios and catch more regressions. For those reasons, modifying existing tests should be the preferred way of extending DAMP coverage.
`custom` tests are using complex documents that should stress a particular tool in various ways. They are all named `custom.${tool}` (for instance `custom.inspector`). The test pages for those tests can be found in [pages/custom](https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/devtools/addon/content/pages/custom).
If your test case requires a dedicated document or can't run next to the other tests in the current `custom` test, follow the instructions below to add a new individual test.
{% endhint %}
```note::
| **Reuse existing tests if possible!**
|
| If a `custom` page already exists for the tool you are testing, try to modify the existing `custom` test rather than adding a new individual test.
|
| New individual tests run separately, in new tabs, and make DAMP slower than just modifying existing tests. Complexifying `custom` test pages should also help cover more scenarios and catch more regressions. For those reasons, modifying existing tests should be the preferred way of extending DAMP coverage.
|
| `custom` tests are using complex documents that should stress a particular tool in various ways. They are all named `custom.${tool}` (for instance `custom.inspector`). The test pages for those tests can be found in [pages/custom](https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/devtools/addon/content/pages/custom).
|
| If your test case requires a dedicated document or can't run next to the other tests in the current `custom` test, follow the instructions below to add a new individual test.
```
This page contains the general documentation for writing DAMP tests. See also:
- [Performance test writing example](./writing-perf-tests-example.html) for a practical example of creating a new test