Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-27 06:43:32 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Bug 1714788 - Fixed more Sphinx warnings in 'mach doc' ,r=sylvestre,webdriver-reviewers DONTBUILD

Browse Source 
Differential Revision: https://phabricator.services.mozilla.com/D116939
This commit is contained in:
surajeet310 2021-06-07 19:28:40 +00:00
parent 79c2eb99d9
commit ea853da3f4
11 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
browser/components/newtab/docs/v2-system-addon/data_dictionary.md
View File

@ -141,7 +141,7 @@ Schema definitions/validations that can be used for tests can be found in `syste
+----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+
| ``card_type`` | [Optional] ("bookmark", "pocket", "trending", "pinned", "search", "spoc", "organic") | :one: |
+----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+
| ``context_id`` | [Optional] An identifier used by the sponsored TopSites telemetry pings. | :one: |
| ``context_id`` | [Optional] An identifier used by the sponsored TopSites telemetry pings. | :one: |
+----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+
| ``search_vendor`` | [Optional] the vendor of the search shortcut, one of ("google", "amazon", "wikipedia", "duckduckgo", "bing", etc.). This field only exists when | |
| | ``card_type = "search"`` | :one: |
@ -334,7 +334,7 @@ This encoding mapping was defined in `system-addon/lib/TelemetryFeed.jsm`
+-------------------+------------------------+
| `showCFRFeatures` | 128 (10000000) |
+-------------------+------------------------+
| `showSponsoredTopSites` | 256 (100000000) |
| `showSponsoredTopSites` | 256 (100000000) |
+-------------------+------------------------+
```

4
devtools/docs/contributing.md
View File

@ -28,9 +28,9 @@ If you're more interested in user experience (think: wireframes, workflows, navi
## Help with BUGS! 🐛🐞 <!--TODO: we might want to split this out to another page with more detail, in addition to this introductory section-->
Not less importantly, we also love **when people file bugs**. They help us a lot and are very valuable (specially when they come with reproducible steps, e.g. in the case of crashes or malfunctions). Here is a short [guide on how to file good bugs](./filing-good-bugs.md) if you've never done it before (or if you need a reminder).
Not less importantly, we also love **when people file bugs**. They help us a lot and are very valuable (specially when they come with reproducible steps, e.g. in the case of crashes or malfunctions). Here is a short [guide on how to file good bugs](./contributing/filing-good-bugs.md) if you've never done it before (or if you need a reminder).
Another thing that is super valuable is **reproducing** bugs (to validate they're happening in more than one environment), and also **completing** bugs, i.e. ensuring the bug has steps to reproduce, a test case, etc, as [mentioned on the guide](./filing-good-bugs.md). This saves time for the person(s) who will work on the bug, as then they can jump straight to fixing or implementing whatever is needed, instead of doing research work. If you can do any of these for a given bug, add a comment with the additional data that you found out.
Another thing that is super valuable is **reproducing** bugs (to validate they're happening in more than one environment), and also **completing** bugs, i.e. ensuring the bug has steps to reproduce, a test case, etc, as [mentioned on the guide](./contributing/filing-good-bugs.md). This saves time for the person(s) who will work on the bug, as then they can jump straight to fixing or implementing whatever is needed, instead of doing research work. If you can do any of these for a given bug, add a comment with the additional data that you found out.
Likewise, if you think that a bug is solved, because you can't reproduce it and doesn't happen any more, this is also useful to know. We can always do with closing more bugs, so please leave a comment detailing as much information as you can provide 😀

2
devtools/docs/contributing/fixing-bugs.md
View File

@ -139,7 +139,7 @@ If not, maybe you'll be able to contribute with one by the time you fix your bug
We have several types of automated tests to help us when developing.
Some, like the linting tests, address coding style; others address functionality, such as unit and integration tests. This page has more [details on types of tests and how to run them](../tests/).
Some, like the linting tests, address coding style; others address functionality, such as unit and integration tests. This page has more [details on types of tests and how to run them](../tests/writing-tests.md).
You might want to run the unit and integration types of tests quite frequently, to confirm you're not breaking anything else. Depending on what you're doing, it might be even possible to run just one test file which addresses the specific change you're implementing:

2
devtools/docs/contributing/react-performance-tips.md
View File

@ -153,7 +153,7 @@ The smaller the tree is, the faster the algorithm is. So it's
useful to limit the changes to a subtree of the full tree. Note that the use of
`shouldComponentUpdate` or `PureComponent` alleviates this issue by cutting off
entire branches from the rendering tree, [we discuss this in more details
below](shouldcomponentupdate-and-purecomponent-avoiding-renders-altogether).
below](#shouldcomponentupdate-and-purecomponent-avoiding-renders-altogether).
Try to change the state as close as possible to where your UI
should change (close in the components tree).

6
docs/performance/activity_monitor_and_top.md
View File

@ -38,14 +38,14 @@ The power-related columns are as follows.
- **Idle wake Ups**:
- In Mac OS 10.9 this measured "package idle exit" wakeups. This
is the same value as
[powermetrics](/powermetrics.md)'
[powermetrics](./powermetrics.md)'
"Pkg idle" measurement (i.e.
`task_power_info::task_platform_idle_wakeups` obtained from the
`task_info` function.)
- In Mac OS 10.10 it appears to have been changed to measure
interrupt-level wakeups (a superset of idle wakeups), which are
less interesting. This is the same value as
[powermetrics](/powermetrics.md)'
[powermetrics](./powermetrics.md)'
"Intr" measurement (i.e.
`task_power_info::task_interrupt_wakeups` obtained from the
`task_info` function.)
@ -57,7 +57,7 @@ The power-related columns are as follows.
Activity Monitor can be useful for cursory measurements, but for more
precise and detailed measurements other tools such as
[powermetrics](/powermetrics.md) are better.
[powermetrics](./powermetrics.md) are better.
### What does "Energy Impact" measure?

4
docs/performance/index.md
View File

@ -18,14 +18,14 @@ explains how to use the Gecko profiler.
## Memory profiling and leak detection tools
* The [Developer Tools Memory panel](memory/memory.md) supports taking heap snapshots, diffing them, computing dominator trees to surface "heavy retainers", and recording allocation stacks.
* [About:memory](memory/about_colon_memory.md) about:memory is the easiest-to-use tool for measuring memory usage in Mozilla code, and is the best place to start. It also lets you do other memory-related operations like trigger GC and CC, dump GC & CC logs, and dump DMD reports. about:memory is built on top of Firefox's memory reporting infrastructure.
* [DMD](memory/DMD.md) is a tool that identifies shortcomings in about:memory's measurements, and can also do multiple kinds of general heap profiling.
* [DMD](memory/dmd.md) is a tool that identifies shortcomings in about:memory's measurements, and can also do multiple kinds of general heap profiling.
* [AWSY](memory/awsy.md) (are we slim yet?) is a memory usage and regression tracker.
* [Bloatview](memory/bloatview.md) prints per-class statistics on allocations and refcounts, and provides gross numbers on the amount of memory being leaked broken down by class. It is used as part of Mozilla's continuous integration testing.
* [Refcount Tracing and Balancing](memory/refcount_tracing_and_balancing.md) are ways to track down leaks caused by incorrect uses of reference counting. They are slow and not particular easy to use, and thus most suitable for use by expert developers.
* [GC and CC Logs](memory/gc_and_cc_logs.md)
* [Leak Gauge](memory/leak_gauge.md) can be generated and analyzed to in various ways. In particular, they can help you understand why a particular object is being kept alive.
* [LogAlloc](https://searchfox.org/mozilla-central/source/memory/replace/logalloc/README) is a tool that dumps a log of memory allocations in Gecko. That log can then be replayed against Firefox's default memory allocator independently or through another replace-malloc library, allowing the testing of other allocators under the exact same workload.
* [See also the documentation on Leak-hunting strategies and tips.](leak_hunting_strategies_and_tips.md)
* [See also the documentation on Leak-hunting strategies and tips.](memory/leak_hunting_strategies_and_tips.md)
## Profiling and performance tools

2
docs/performance/memory/about_colon_memory.md
View File

@ -168,7 +168,7 @@ there are various things worth pointing out.
that is not measured by any memory reporter. This is typically
10--20% of "explicit". If it gets higher, it indicates that
additional memory reporters should be added.
[DMD](DMD.md")
[DMD](./dmd.md)
can be used to determine where these memory reporters should be
added.
- There are measurements for other content such as images and workers,

2
docs/performance/memory/leak_hunting_strategies_and_tips.md
View File

@ -47,7 +47,7 @@ small and easy to identify using GC-based leak detection.)
Tool Finds Platforms Requires
Leak tools for large object graphs
[Leak Gauge](leak_gauge.md) Windows, documents, and docshells only All platforms Any build
[GC and CC logs](GC_and_CC_logs.md) JS objects, DOM objects, many other kinds of objects All platforms Any build
[GC and CC logs](gc_and_cc_logs.md) JS objects, DOM objects, many other kinds of objects All platforms Any build
Leak tools for medium-size object graphs
[BloatView](bloatview.md), [refcount tracing and balancing](refcount_tracing_and_balancing.md) Objects that implement `nsISupports` or use `MOZ_COUNT_{CTOR,DTOR}` All tier 1 platforms Debug build (or build opt with `--enable-logrefcnt`)
Leak tools for debugging memory growth that is cleaned up on shutdown

2
docs/performance/power_profiling_overview.md
View File

@ -92,7 +92,7 @@ Intel processors have model-specific registers (MSRs) containing
measurements of how much time is spent in different C-states, and tools
such as [powermetrics](powermetrics.md)
(Mac), powertop and
[turbostat](/turbostat.md) (Linux) can
[turbostat](turbostat.md) (Linux) can
expose this information.
A *wakeup* occurs when a core or package transitions from an idle state

2
docs/performance/powermetrics.md
View File

@ -4,7 +4,7 @@
high-quality power-related measurements. It is most useful for getting
CPU, GPU and wakeup measurements in a precise and easily scriptable
fashion (unlike [Activity Monitor and
top](/activity_monitor_and_top))
top](activity_monitor_and_top.md))
especially in combination with
[rapl](tools_power_rapl.md) via the
`mach power` command. This document describes the version of

4
remote/marionette/doc/CodeStyle.md
View File

@ -165,7 +165,7 @@ We very much welcome your help in doing version control archeology
to make this happen!
The practical details of working on the Marionette code is outlined
in [CONTRIBUTING.md], but generally you do not have to re-build
in [Contributing.md], but generally you do not have to re-build
Firefox when changing code. Any change to remote/marionette/*.js
will be picked up on restarting Firefox. The only notable exception
is remote/components/marionette.js, which does require
@ -178,7 +178,7 @@ a re-build.
[copying header]: https://www.mozilla.org/en-US/MPL/headers/
[public domain]: https://creativecommons.org/publicdomain/zero/1.0/
[MPL]: https://www.mozilla.org/en-US/MPL/2.0/
[CONTRIBUTING.md]: ../CONTRIBUTING.md
[Contributing.md]: ./Contributing.md
Python