Ports URL markdown linter rules from web.dev (#1901)

* Ports over markdown URL linting rules from web.dev.

* Fixes bad MDN links with locales in them.

* Fixes absolute d.c.c. links in all Markdown files to be relative instead.

* Had to hack around a type error.

* Fixes JS lint issue.

.remarkrc.js

@@ -46,4 +46,5 @@ exports.plugins = [
 
   // Custom plugins.
   require('./tools/linting/no-unescaped-template-tags.js'),
+  require('./tools/linting/bad-urls.js'),
 ];

site/en/blog/_example/index.md

@@ -60,8 +60,8 @@ A few rules:
 - Make sure all of your images have `alt` text unless they are purely
   decorative.
 - Make sure authors appear in the `authorsData.json` file and that they have
-  uploaded a headshot to our image CDN. See [How to add an author](https://developer.chrome.com/docs/handbook/how-to/add-an-author/).
-- Make sure tags have been added to `tags.yml`. See [How to add a tag](https://developer.chrome.com/docs/handbook/how-to/add-a-tag/).
+  uploaded a headshot to our image CDN. See [How to add an author](/docs/handbook/how-to/add-an-author/).
+- Make sure tags have been added to `tags.yml`. See [How to add a tag](/docs/handbook/how-to/add-a-tag/).
 - Code blocks should use triple backticks and include a language name. Example:
 
 ```html

site/en/blog/auto-dark-theme/index.md

@@ -14,7 +14,7 @@ tags:
   - origin-trials
 ---
 
-Chrome 96 introduces an [origin trial](https://developer.chrome.com/blog/origin-trials/) for Auto Dark Themes on Android.
+Chrome 96 introduces an [origin trial](/blog/origin-trials/) for Auto Dark Themes on Android.
 With this feature, the browser applies an automatically generated dark theme to light themed sites,
 when the user has opted into dark themes in the operating system.
 Users can opt-out of dark themes by either disabling the option on the OS level or in a specific setting in Chrome.

site/en/blog/autoplay/index.md

@@ -296,7 +296,7 @@ on the Chromium site.
 [permissions policy for autoplay]: https://github.com/WICG/feature-policy/blob/main/features.md
 [policy list]: https://chromeenterprise.google/policies/
 [progressive-web-apps]: https://web.dev/progressive-web-apps/
-[promise]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
+[promise]: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise
 [pull request]: https://github.com/GoogleChromeLabs/airhorn/pull/37
 [rejected]: https://developers.google.com/web/updates/2017/06/play-request-was-interrupted
-[web audio api]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API
+[web audio api]: https://developer.mozilla.org/docs/Web/API/Web_Audio_API

site/en/blog/coep-credentialless-origin-trial/index.md

@@ -31,10 +31,10 @@ Some web APIs increase the risk of side-channel attacks such as
 mitigate that risk, browsers offer an opt-in-based isolated environment called
 [cross-origin isolation](https://web.dev/coop-coep/). With a cross-origin
 isolated state, the webpage can use privileged features including
-[`SharedArrayBuffer`](https://developer.chrome.com/blog/enabling-shared-array-buffer/),
+[`SharedArrayBuffer`](/blog/enabling-shared-array-buffer/),
 [`performance.measureUserAgentSpecificMemory()`](https://web.dev/monitor-total-page-memory-usage/)
 and [high-precision timers with better
-resolution](https://developer.chrome.com/blog/cross-origin-isolated-hr-timers/)
+resolution](/blog/cross-origin-isolated-hr-timers/)
 while isolating the origin from others unless they are opted in.
 
 The webpage must send two HTTP headers to enable cross-origin isolation:
@@ -150,7 +150,7 @@ You can register for it to allowlist your website to make the
 `Cross-Origin-Embedder-Policy: credentialless` header to take effect.
 
 1. [Request a
-   token](https://developer.chrome.com/origintrials/#/view_trial/3036552048754556929)
+   token](/origintrials/#/view_trial/3036552048754556929)
    for your origin.
 2. Apply an `Origin-Trial` HTTP header to the document you want to apply
    `Cross-Origin-Embedder-Policy: credentialless` header. The resulting response
@@ -181,7 +181,7 @@ cross-origin isolation:
 
 Those who registered for [the Chrome origin trial to extend the
 SharedArrayBuffer
-change](https://developer.chrome.com/blog/enabling-shared-array-buffer/) due to
+change](/blog/enabling-shared-array-buffer/) due to
 the above obstacles might be wondering when it will be terminated. Originally we
 announced that it will be terminated in Chrome 96, but we have decided to
 postpone this to Chrome 103.
@@ -195,7 +195,7 @@ postpone this to Chrome 103.
 * [A guide to enable cross-origin
   isolation](https://web.dev/cross-origin-isolation-guide/)
 * [SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome
-  92](https://developer.chrome.com/blog/enabling-shared-array-buffer/)
+  92](/blog/enabling-shared-array-buffer/)
 
 Photo by [Martin
 Adams](https://unsplash.com/@martinadams?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

site/en/blog/crx-scripting-api/index.md

@@ -300,7 +300,7 @@ improving the developer experience. By introducing `chrome.scripting` in Manifes
 to help clean up the Tabs API, to reimagine `executeScript` for a more secure extensions platform,
 and to lay the groundwork for new scripting capabilities that will be coming later this year.
 
-[content-scripts]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts
+[content-scripts]: https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/Content_scripts
 [iframe-demo]: https://simple-iframe-demo.glitch.me/
 [scripting-api]: /docs/extensions/reference/scripting/
 [scripting-executescript]: /docs/extensions/reference/scripting/#method-executeScript

site/en/blog/csp-issues/index.md

@@ -127,7 +127,7 @@ Once we had settled on which information we wanted to make available, we needed
 
 ### Step 3: issue detection
 
-To make the information available to the Chrome DevTools Protocol (CDP) in the format described in the last section, we needed to find the place where the information was actually available in the back-end. Fortunately, the CSP code already had a bottle-neck used for report-only mode, where we could hook into: [`ContentSecurityPolicy::ReportViolation`](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/frame/csp/content_security_policy.cc;l=1128;drc=c7101018b828047f762bab9f0f129cdd53e03180) reports issues to an (optional) reporting end-point that can be configured in the [CSP HTTP header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-to). Most of the information we wanted to report was already available, so no big changes in the back-end were necessary for our instrumentation to work.
+To make the information available to the Chrome DevTools Protocol (CDP) in the format described in the last section, we needed to find the place where the information was actually available in the back-end. Fortunately, the CSP code already had a bottle-neck used for report-only mode, where we could hook into: [`ContentSecurityPolicy::ReportViolation`](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/frame/csp/content_security_policy.cc;l=1128;drc=c7101018b828047f762bab9f0f129cdd53e03180) reports issues to an (optional) reporting end-point that can be configured in the [CSP HTTP header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Content-Security-Policy/report-to). Most of the information we wanted to report was already available, so no big changes in the back-end were necessary for our instrumentation to work.
 
 
 ### Step 4: save and display the issues
@@ -171,7 +171,7 @@ After iteration, we then arrived at:
 
 As you can see, involving the feature team and DevRel makes the description a lot more clear and precise!
 
-CSP issues on your page can also be discovered in the [tab specifically dedicated to CSP violations](https://developer.chrome.com/blog/new-in-devtools-89/#csp).
+CSP issues on your page can also be discovered in the [tab specifically dedicated to CSP violations](/blog/new-in-devtools-89/#csp).
 
 
 ## Debugging Trusted Types problems
@@ -196,7 +196,7 @@ Hence, moving that part of the code to Blink or any embedder sounds like a logic
 
 ### Break-on-violation (in report-only mode)
 
-Currently, the [only way of debugging TT violations](https://developer.chrome.com/blog/new-in-devtools-89/#trusted-types) is by setting breakpoints on JS exceptions. Since enforced TT violations will trigger an exception, this feature can be somehow useful. However, in real world scenarios you need a more fine-grained control over TT violations. In particular, we would like to break only on TT violations (not other exceptions), break also in report-only mode and distinguish between the different types of TT violations.
+Currently, the [only way of debugging TT violations](/blog/new-in-devtools-89/#trusted-types) is by setting breakpoints on JS exceptions. Since enforced TT violations will trigger an exception, this feature can be somehow useful. However, in real world scenarios you need a more fine-grained control over TT violations. In particular, we would like to break only on TT violations (not other exceptions), break also in report-only mode and distinguish between the different types of TT violations.
 
 DevTools already has support for a wide variety of breakpoints so the architecture is quite extensible. Adding a new breakpoint type requires changes in the backend (Blink), CDP and the frontend.
 We should introduce a new CDP command, let's call it `setBreakOnTTViolation`. This command will be used by the frontend to tell the backend on what sort of TT violations it should break. The backend, in particular `InspectorDOMDebuggerAgent`, will provide a "probe", `onTTViolation()` that will be called every time a TT violation occurs. Then, `InspectorDOMDebuggerAgent` will check if that violation should trigger a breakpoint, and if that is the case it will send a message to the frontend to pause the execution.
@@ -206,10 +206,10 @@ We should introduce a new CDP command, let's call it `setBreakOnTTViolation`. Th
 
 Since the issues described here were introduced, the **Issues** tab has undergone quite some changes:
 
-- Its [interconnectedness](https://developer.chrome.com/blog/new-in-devtools-89/#trusted-type-link) with other panels in DevTools has been improved.
-- Reporting of a number of further problems has moved to the **Issues** tab: [low-contrast](https://developer.chrome.com/blog/new-in-devtools-90/#low-contrast), [trusted web-activity](https://developer.chrome.com/blog/new-in-devtools-90/#twa), [quirks mode](https://developer.chrome.com/blog/new-in-devtools-92/#quirks-mode), [attribution reporting API](https://developer.chrome.com/blog/new-in-devtools-93/#attribution-reporting) and
-[CORS-related issues](https://developer.chrome.com/blog/new-in-devtools-93/#cors) among others.
-- An opportunity to [hide issues](https://developer.chrome.com/blog/new-in-devtools-94/#hide-issues) was introduced
+- Its [interconnectedness](/blog/new-in-devtools-89/#trusted-type-link) with other panels in DevTools has been improved.
+- Reporting of a number of further problems has moved to the **Issues** tab: [low-contrast](/blog/new-in-devtools-90/#low-contrast), [trusted web-activity](/blog/new-in-devtools-90/#twa), [quirks mode](/blog/new-in-devtools-92/#quirks-mode), [attribution reporting API](/blog/new-in-devtools-93/#attribution-reporting) and
+[CORS-related issues](/blog/new-in-devtools-93/#cors) among others.
+- An opportunity to [hide issues](/blog/new-in-devtools-94/#hide-issues) was introduced
 
 Moving forward, we plan to use the **Issues** tab to surface more problems, which will make it possible to unload the Console of the unreadable error-message flow in the long run.
 

site/en/blog/css-grid-tooling/index.md

@@ -101,7 +101,7 @@ where each `GridNodeHighlightConfig` contains information about which node to dr
 
 ## Real-time Grid badges
 
-To help developers easily toggle on and off the Grid overlays, we decided to add small badges next to Grid containers in the [DOM Tree](https://developer.chrome.com/docs/devtools/dom/). These badges can also help developers identify Grid containers in their DOM structures.
+To help developers easily toggle on and off the Grid overlays, we decided to add small badges next to Grid containers in the [DOM Tree](/docs/devtools/dom/). These badges can also help developers identify Grid containers in their DOM structures.
 
 {% Img src="image/1D9D0Ls1ATa2ZPA9x2ZWrGFyZzT2/JuOPl5pjlitbTTptxRw4.png", alt="ALT_TEXT_HERE", width="608", height="322" %}
 

site/en/blog/deps-rems-94/index.md

@@ -21,9 +21,9 @@ stable version in late September, 2021.
 Removal is expected in Chrome 97. The Web SQL Database standard was first
 proposed in April 2009 and abandoned in November 2010. Gecko never implemented
 this feature and WebKit deprecated this feature in 2019. The W3C encourages
-[Web Storage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API)
+[Web Storage](https://developer.mozilla.org/docs/Web/API/Web_Storage_API)
 and
-[Indexed Database](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)
+[Indexed Database](https://developer.mozilla.org/docs/Web/API/IndexedDB_API)
 for those needing alternatives.
 
 Developers should expect that WebSQL itself will be deprecated and removed when

site/en/blog/deps-rems-95/index.md

@@ -61,7 +61,7 @@ Chrome's legacy U2F API for interacting with security keys is deprecated. It
 will be disabled by default in Chrome 98.
 
 Affected sites should migrate to the [Web Authentication
-API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API).
+API](https://developer.mozilla.org/docs/Web/API/Web_Authentication_API).
 Credentials that were originally registered via the U2F API can be challenged
 via web authentication. USB security keys that are supported by the U2F API are
 also supported by the Web Authentication API. U2F security keys themselves are
@@ -93,15 +93,15 @@ were implemented:
 +   Gated U2F API requests behind a user permission prompt.
 
 The permission prompt can be suppressed by enrolling in the [U2FSecurityKeyAPI
-deprecation trial](https://developer.chrome.com/origintrials/#/view_trial/-6366963973195038719)
+deprecation trial](/origintrials/#/view_trial/-6366963973195038719)
 or enabling the [U2fSecurityKeyApiEnabled](https://chromeenterprise.google/policies/#U2fSecurityKeyApiEnabled)
 enterprise policy.
 
 ### Chrome 98
 
 Beta expected in early January 2022, stable in February. The U2F API will be
 disabled by default. Only sites enrolled in the [deprecation
-trial](https://developer.chrome.com/origintrials/#/view_trial/-6366963973195038719)
+trial](/origintrials/#/view_trial/-6366963973195038719)
 or enterprises that turned on the
 [U2fSecurityKeyApiEnabled](https://chromeenterprise.google/policies/#U2fSecurityKeyApiEnabled)
 policy will be able to use U2F at this point.

site/en/blog/deps-rems-97/index.md

@@ -33,9 +33,9 @@ removed](https://www.chromestatus.com/feature/5695324321480704) as of Chrome
 The Web SQL Database standard was first proposed in April 2009 and abandoned in
 November 2010. Gecko never implemented this feature and WebKit deprecated it in
 2019. The W3C encourages
-[Web Storage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API)
+[Web Storage](https://developer.mozilla.org/docs/Web/API/Web_Storage_API)
 and
-[Indexed Database](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)
+[Indexed Database](https://developer.mozilla.org/docs/Web/API/IndexedDB_API)
 for those needing alternatives.
 
 ## Remove SDP Plan B

site/en/blog/enabling-shared-array-buffer/index.md

@@ -60,7 +60,7 @@ Cross-Origin-Opener-Policy: same-origin
 
 Once you do this, your page will not be able to load cross-origin content unless
 the resource explicitly allows it via a [`Cross-Origin-Resource-Policy`][corp]
-header or [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) headers
+header or [CORS](https://developer.mozilla.org/docs/Web/HTTP/CORS) headers
 (`Access-Control-Allow-*` and so forth).
 
 There's also a [reporting
@@ -147,7 +147,7 @@ These APIs have a 'legacy' behavior that allows content from other origins to be
 used without opt-in from the other origin. These requests are made with the
 cookies of the other origin, so it's a full 'logged in' request. Nowadays, new
 APIs require the other origin to opt-in using
-[CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).
+[CORS](https://developer.mozilla.org/docs/Web/HTTP/CORS).
 
 We worked around these legacy APIs by preventing content from entering the
 webpage's process if it looked 'incorrect', and called it [cross-origin read
@@ -170,8 +170,8 @@ This declaration is done via [COOP and COEP headers](https://web.dev/coop-coep/)
 served with the page. The browser enforces that, and in exchange the page gains
 access to `SharedArrayBuffer` and other APIs with similar powers. Other origins
 can opt-in to content embedding via
-[`Cross-Origin-Resource-Policy`](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)>)
-or [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).
+[`Cross-Origin-Resource-Policy`](<https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)>)
+or [CORS](https://developer.mozilla.org/docs/Web/HTTP/CORS).
 
 Firefox was the first to ship `SharedArrayBuffer` with this restriction, in
 version 79 (July 2020).
@@ -214,6 +214,6 @@ href="https://unsplash.com/@yeeeeeeha?utm_source=unsplash&amp;utm_medium=referra
 Gregoire</a> on <a
 href="https://unsplash.com/s/photos/padlocks?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a>
 
-[mdn]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
-[compat]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#browser_compatibility
-[corp]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)
+[mdn]: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
+[compat]: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#browser_compatibility
+[corp]: https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)