diff --git a/browser/components/newtab/docs/v2-system-addon/data_dictionary.md b/browser/components/newtab/docs/v2-system-addon/data_dictionary.md index 99825cd2599c..346755955cd7 100644 --- a/browser/components/newtab/docs/v2-system-addon/data_dictionary.md +++ b/browser/components/newtab/docs/v2-system-addon/data_dictionary.md @@ -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) | +-------------------+------------------------+ ``` diff --git a/devtools/docs/contributing.md b/devtools/docs/contributing.md index 094efd0c47f3..51c5ec374425 100644 --- a/devtools/docs/contributing.md +++ b/devtools/docs/contributing.md @@ -28,9 +28,9 @@ If you're more interested in user experience (think: wireframes, workflows, navi ## Help with BUGS! 🐛🐞 -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 😀 diff --git a/devtools/docs/contributing/fixing-bugs.md b/devtools/docs/contributing/fixing-bugs.md index d2df3e377dce..67d6075f3440 100644 --- a/devtools/docs/contributing/fixing-bugs.md +++ b/devtools/docs/contributing/fixing-bugs.md @@ -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: diff --git a/devtools/docs/contributing/react-performance-tips.md b/devtools/docs/contributing/react-performance-tips.md index db6f92089552..15b2cf0f6817 100644 --- a/devtools/docs/contributing/react-performance-tips.md +++ b/devtools/docs/contributing/react-performance-tips.md @@ -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). diff --git a/docs/performance/activity_monitor_and_top.md b/docs/performance/activity_monitor_and_top.md index b4ad71310884..4e687c4dfed6 100644 --- a/docs/performance/activity_monitor_and_top.md +++ b/docs/performance/activity_monitor_and_top.md @@ -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? diff --git a/docs/performance/index.md b/docs/performance/index.md index 78d32c77ac4e..d9c82892e6cc 100644 --- a/docs/performance/index.md +++ b/docs/performance/index.md @@ -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 diff --git a/docs/performance/memory/about_colon_memory.md b/docs/performance/memory/about_colon_memory.md index 07d575a7f390..ab9dc8106272 100644 --- a/docs/performance/memory/about_colon_memory.md +++ b/docs/performance/memory/about_colon_memory.md @@ -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, diff --git a/docs/performance/memory/leak_hunting_strategies_and_tips.md b/docs/performance/memory/leak_hunting_strategies_and_tips.md index 549c406d8579..3a8f0e41e7da 100644 --- a/docs/performance/memory/leak_hunting_strategies_and_tips.md +++ b/docs/performance/memory/leak_hunting_strategies_and_tips.md @@ -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 diff --git a/docs/performance/power_profiling_overview.md b/docs/performance/power_profiling_overview.md index 53da53e7f6cc..f6d0585aa2f0 100644 --- a/docs/performance/power_profiling_overview.md +++ b/docs/performance/power_profiling_overview.md @@ -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 diff --git a/docs/performance/powermetrics.md b/docs/performance/powermetrics.md index 2deacb608f98..614c669b443f 100644 --- a/docs/performance/powermetrics.md +++ b/docs/performance/powermetrics.md @@ -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 diff --git a/remote/marionette/doc/CodeStyle.md b/remote/marionette/doc/CodeStyle.md index 63474dace759..ca1063e52d20 100644 --- a/remote/marionette/doc/CodeStyle.md +++ b/remote/marionette/doc/CodeStyle.md @@ -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