Bug 1748845 - Update source-relative links in devtools docs, r=firefox-source-docs-reviewers,Honza,sylvestre

Differential Revision: https://phabricator.services.mozilla.com/D135382

devtools/docs/contributor/frontend/react.md

@@ -132,7 +132,7 @@ const App = React.createClass({
 
 If you are using something like Redux to manage state this is handled
 automatically for you with the library you use to bind Redux with
-React. See more in [Redux](redux.html).
+React. See more in [Redux](redux.md).
 
 ## DOM Diffing
 
@@ -154,4 +154,4 @@ just make sure the virtual DOM has what it should.
 ## Next
 
 Read the [React Guidelines](react-guidelines.md) next to learn how to
-write React code specifically for the devtools.
+write React code specifically for the devtools.

devtools/docs/contributor/frontend/redux.md

@@ -5,7 +5,7 @@ concepts, so go read them.
 
 # Quick Intro
 
-Just like the [React introduction](react.html), this is a quick
+Just like the [React introduction](react.md), this is a quick
 introduction to redux, focusing on how it fits into React and why we
 chose it.
 
@@ -157,4 +157,4 @@ rendered with react.
 ## Next
 
 Read the [Redux Guidelines](redux-guidelines.md) next to learn how to
-write React code specifically for the devtools.
+write React code specifically for the devtools.

devtools/docs/contributor/frontend/telemetry.md

@@ -304,7 +304,7 @@ Notes:
 
 The code for the tabs uses their ids to automatically report telemetry when you switch between panels, so you don't need to explicitly call `toolOpened` and `toolClosed` on top level panels.
 
-You will still need to call those functions on subpanels, or tools such as about:debugging which are not opened as tabs.
+You will still need to call those functions on subpanels, or tools such as `about:debugging` which are not opened as tabs.
 
 #### Testing
 
@@ -426,7 +426,7 @@ Click [here](https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Data_Co
 
 ### Local data
 
-Go to [about:telemetry](about:telemetry) to see stats relating to your local instance.
+Go to `about:telemetry` to see stats relating to your local instance.
 
 ### Global data
 

devtools/docs/contributor/getting-started/development-profiles.md

@@ -39,7 +39,7 @@ Create a new profile, and name it `development`. Then start Firefox by clicking
 
 Next time you start Firefox with `./mach run -P development`, the new profile will be automatically used, and settings will persist between browser launches.
 
-It's now time to [start contributing](../contributing.html)! 😃
+It's now time to [start contributing](../contributing.md)! 😃
 
 ---
 

devtools/docs/contributor/tests/writing-perf-tests.md

@@ -1,6 +1,6 @@
 # Writing new DAMP performance tests
 
-See [DAMP Performance tests](performance-tests.md) for an overall description of our performance tests.
+See [DAMP Performance tests](performance-tests-damp.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.
 
 ```note::
@@ -16,8 +16,8 @@ Here, we will describe how to write a new test and register it to run in DAMP.
 ```
 
 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
-- [Performance test writing tips](./writing-perf-tests-tips.html) for detailed tips on how to write a good and efficient test
+- [Performance test writing example](writing-perf-tests-example.md) for a practical example of creating a new test
+- [Performance test writing tips](writing-perf-tests-tips.md) for detailed tips on how to write a good and efficient test
 
 ## Test location
 

devtools/docs/contributor/tools/highlighters.md

@@ -17,7 +17,7 @@ But there can be a wide variety of highlighters. In particular, highlighters are
 
 ## Using highlighters
 
-Highlighters run on the debuggee side, not on the toolbox side. This is so that it's possible to highlight elements on a remote device for instance. This means you need to go through the [Remote Debugging Protocol](protocol.md) to use a highlighter.
+Highlighters run on the debuggee side, not on the toolbox side. This is so that it's possible to highlight elements on a remote device for instance. This means you need to go through the [Remote Debugging Protocol](../backend/protocol.md) to use a highlighter.
 
 The InspectorFront provides the following method:
 

devtools/docs/contributor/tools/memory-panel.md

@@ -22,14 +22,16 @@ The memory tool is built of three main elements:
 
 Unlike other tools (such as the JavaScript debugger), the memory tool makes very
 little use of the Remote DevTools Server and the actors that reside in it. Use
-of the [`MemoryActor`](devtools/server/actors/memory.js) is limited to toggling
-allocation stack recording on and off, and transferring heap snapshots from the
-debuggee (which is on the server) to the `HeapAnalysesWorker` (which is on the
-client). A nice benefit that naturally emerges, is that supporting "legacy"
-servers (eg, using Firefox Developer Edition as a client to remote debug a
-release Firefox for Android server) is a no-op. As we add new analyses, we can
-run them on snapshots taken on old servers no problem. The only requirement is
-that changes to the snapshot format itself remain backwards compatible.
+of the
+[`MemoryActor`](https://searchfox.org/mozilla-central/source/devtools/server/actors/memory.js)
+is limited to toggling allocation stack recording on and off, and transferring
+heap snapshots from the debuggee (which is on the server) to the
+`HeapAnalysesWorker` (which is on the client). A nice benefit that naturally
+emerges, is that supporting "legacy" servers (eg, using Firefox Developer
+Edition as a client to remote debug a release Firefox for Android server) is a
+no-op. As we add new analyses, we can run them on snapshots taken on old servers
+no problem. The only requirement is that changes to the snapshot format itself
+remain backwards compatible.
 
 ## `JS::ubi::Node`
 
@@ -103,9 +105,9 @@ The `DeserializedNode` and `DeserializedEdge` classes implement the
 than the live heap graph operate on these classes (unknowingly, of course).
 
 For more details, see the
-[`mozilla::devtools::HeapSnapshot`](devtools/shared/heapsnapshot/HeapSnapshot.cpp)
+[`mozilla::devtools::HeapSnapshot`](https://searchfox.org/mozilla-central/source/devtools/shared/heapsnapshot/HeapSnapshot.cpp)
 and
-[`mozilla::devtools::Deserialized{Node,Edge}`](devtools/shared/heapsnapshot/DeserializedNode.h)
+[`mozilla::devtools::Deserialized{Node,Edge}`](https://searchfox.org/mozilla-central/source/devtools/shared/heapsnapshot/DeserializedNode.h)
 classes.
 
 ### Heap Analyses
@@ -114,14 +116,15 @@ Heap analyses operate on `JS::ubi::Node` graphs without knowledge of whether
 that graph is backed by the live heap graph or an offline heap snapshot. They
 must make sure never to allocate GC things or modify the live heap graph.
 
-In general, analyses are implemented in their own `js/public/Ubi{AnalysisName}.h`
-header (eg `js/public/UbiCensus.h`), and are exposed to chrome JavaScript code
-via a method on the [`HeapSnapshot`](dom/webidl/HeapSnapshot.webidl) webidl
-interface.
+In general, analyses are implemented in their own
+`js/public/Ubi{AnalysisName}.h` header (eg `js/public/UbiCensus.h`), and are
+exposed to chrome JavaScript code via a method on the
+[`HeapSnapshot`](https://searchfox.org/mozilla-central/source/dom/webidl/HeapSnapshot.webidl)
+webidl interface.
 
 For each analysis we expose to chrome JavaScript on the `HeapSnapshot` webidl
 interface, there is a small amount of glue code in Gecko. The
-[`mozilla::devtools::HeapSnapshot`](devtools/shared/heapsnapshot/HeapSnapshot.h)
+[`mozilla::devtools::HeapSnapshot`](https://searchfox.org/mozilla-central/source/devtools/shared/heapsnapshot/HeapSnapshot.h)
 C++ class implements the webidl interface. The analyses methods (eg
 `ComputeDominatorTree`) take the deserialized nodes and edges from the heap
 snapshot, create `JS::ubi::Node`s from them, call the analyses from
@@ -129,7 +132,8 @@ snapshot, create `JS::ubi::Node`s from them, call the analyses from
 JavaScript.
 
 For API documentation on running specific analyses, see the
-[`HeapSnapshot`](dom/webidl/HeapSnapshot.webidl) webidl interface.
+[`HeapSnapshot`](https://searchfox.org/mozilla-central/source/dom/webidl/HeapSnapshot.webidl)
+webidl interface.
 
 ### Testing `JS::ubi::Node`, Snapshots, and Analyses