Fix links (mdn#36158)

* fix links

* Update files/en-us/learn/tools_and_testing/understanding_client-side_tools/package_management/index.md

---------

Co-authored-by: Joshua Chen <[email protected]>

files/en-us/learn/tools_and_testing/understanding_client-side_tools/package_management/index.md

@@ -70,7 +70,7 @@ To see local dependencies really shine, all you need to do is try to download an
 
 For a package manager to work, it needs to know where to install packages from, and this comes in the form of a package registry. The registry is a central place where a package is published and thus can be installed from. npm, as well as being a package manager, is also the name of the most commonly-used package registry for JavaScript packages. The npm registry exists at [npmjs.com](https://www.npmjs.com/).
 
-npm is not the only option. You could manage your own package registry — products like [Microsoft Azure](https://azure.microsoft.com/) allow you to create proxies to the npm registry (so you can override or lock certain packages), [GitHub also offers a package registry service](https://github.com/features/packages), and there will be likely more options appearing as time goes on.
+npm is not the only option. You could manage your own package registry — products like [Microsoft Azure](https://azure.microsoft.com/) allow you to create proxies to the npm registry (so you can override or lock certain packages), [GitHub also offers a package registry service](https://docs.github.com/en/packages), and there will be likely more options appearing as time goes on.
 
 What is important is that you ensure you've chosen the best registry for you. Many projects will use npm, and we'll stick to this in our examples throughout the rest of the module.
 

files/en-us/mozilla/add-ons/webextensions/manifest.json/background/index.md

@@ -167,7 +167,7 @@ Support for the `scripts`, `page`, and `service_worker` properties varies betwee
   - supports `background.scripts` (and `background.page`) in Manifest V2 extensions only.
   - before Chrome 121, Chrome refuses to load a Manifest V3 extension with `background.scripts` or `background.page` present. From Chrome 121, their presence in a Manifest V3 extension is ignored.
 - Firefox:
-  - `background.service_worker` is not supported (see [Firefox bug 1573659](https://bugzilla.mozilla.org/show_bug.cgi?id=1573659)).
+  - `background.service_worker` is not supported (see [Firefox bug 1573659](https://bugzil.la/1573659)).
   - supports `background.scripts` (or `background.page`) if `service_worker` is not specified or the service worker feature is disabled. Before Firefox 120, Firefox did not start the background page if `service_worker` was present (see [Firefox bug 1860304](https://bugzil.la/1860304)). From Firefox 121, the background page starts as expected, regardless of the presence of `service_worker`.
 - Safari:
   - supports `background.service_worker`.

files/en-us/mozilla/add-ons/webextensions/your_second_webextension/index.md

@@ -112,7 +112,7 @@ If you choose to supply your own icon, It should be 48x48 pixels. You could also
 
 The toolbar button also needs an icon, and our manifest.json promised that we would have an icon for the toolbar at "icons/beasts-32.png".
 
-Save an icon named "beasts-32.png" in the "icons" directory. You could use [the one from our example](https://raw.githubusercontent.com/mdn/webextensions-examples/main/beastify/icons/beasts-32.png), which is taken from the [IconBeast Lite icon set](http://www.iconbeast.com/free/) and used under the terms of its [license](http://www.iconbeast.com/faq/).
+Save an icon named "beasts-32.png" in the "icons" directory. You could use [the one from our example](https://raw.githubusercontent.com/mdn/webextensions-examples/main/beastify/icons/beasts-32.png), which is taken from the [IconBeast Lite icon set](https://www.iconbeast.com/free/) and used under the terms of its [license](https://www.iconbeast.com/faq/).
 
 If you don't supply a popup, then a click event is dispatched to your extension when the user clicks the button. If you do supply a popup, the click event is not dispatched, but instead, the popup is opened. We want a popup, so let's create that next.
 

files/en-us/web/api/audiolistener/index.md

@@ -45,7 +45,7 @@ It is important to note that there is only one listener per context and that it
   - : Sets the position of the listener.
 
 > [!NOTE]
-> Although these methods are deprecated they are currently the only way to set the orientation and position in Firefox (see [Firefox bug 1283029](https://bugzilla.mozilla.org/show_bug.cgi?id=1283029)).
+> Although these methods are deprecated they are currently the only way to set the orientation and position in Firefox (see [Firefox bug 1283029](https://bugzil.la/1283029)).
 
 ## Deprecated features
 

files/en-us/web/api/htmlmediaelement/playbackrate/index.md

@@ -38,5 +38,5 @@ console.log(obj.playbackRate); // Expected Output: 1
 ## See also
 
 - {{domxref("HTMLMediaElement")}}: Interface used to define the `HTMLMediaElement.playbackRate` property
-- Browser bug reports to support negative `playbackRate` in [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1468019) and [Blink](https://issues.chromium.org/issues/40410591) (Chrome, etc.)
+- Browser bug reports to support negative `playbackRate` in [Firefox](https://bugzil.la/1468019) and [Blink](https://crbug.com/40410591) (Chrome, etc.)
 - The Web Hypertext Application Technology Working Group (WHATWG) [issue to require support for negative `playbackRate`](https://github.com/whatwg/html/issues/3754)

files/en-us/web/api/performance/now/index.md

@@ -56,9 +56,9 @@ currentTime = performance.timeOrigin + performance.now();
 
 The specification (Level 2) requires that `performance.now()` should tick during sleep. It appears that only Firefox on Windows, and Chromiums on Windows keep ticking during sleep. Relevant browser bugs for other operating systems:
 
-- Chrome/Chromium ([bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1206450))
-- Firefox ([bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1709767))
-- Safari/WebKit ([bug](https://bugs.webkit.org/show_bug.cgi?id=225610))
+- Chrome/Chromium ([bug](https://crbug.com/1206450))
+- Firefox ([bug](https://bugzil.la/1709767))
+- Safari/WebKit ([bug](https://webkit.org/b/225610))
 
 More details can also be found in the specification issue [hr-time#115](https://github.com/w3c/hr-time/issues/115#issuecomment-1172985601).
 

files/en-us/web/api/webrtc_api/using_data_channels/index.md

@@ -76,11 +76,11 @@ Currently, it's not practical to use `RTCDataChannel` for messages larger than 6
 
 This eventually became a problem. Over time, various applications (including those implementing WebRTC) began to use SCTP to transmit larger and larger messages. Eventually it was realized that when the messages become too large, it's possible for the transmission of a large message to block all other data transfers on that data channel—including critical signaling messages.
 
-This will become an issue when browsers properly support the current standard for supporting larger messages—the end-of-record (EOR) flag that indicates when a message is the last one in a series that should be treated as a single payload. This is implemented in Firefox 57, but is not yet implemented in Chrome (see [Chromium Bug 7774](https://bugs.chromium.org/p/webrtc/issues/detail?id=7774)). With EOR support in place, `RTCDataChannel` payloads can be much larger (officially up to 256 KiB, but Firefox's implementation caps them at a whopping 1 GiB). Even at 256 KiB, that's large enough to cause noticeable delays in handling urgent traffic. If you go even larger, the delays can become untenable unless you are certain of your operational conditions.
+This will become an issue when browsers properly support the current standard for supporting larger messages—the end-of-record (EOR) flag that indicates when a message is the last one in a series that should be treated as a single payload. This is implemented in Firefox 57, but is not yet implemented in Chrome (see [Chromium Bug 7774](https://crbug.com/webrtc/7774)). With EOR support in place, `RTCDataChannel` payloads can be much larger (officially up to 256 KiB, but Firefox's implementation caps them at a whopping 1 GiB). Even at 256 KiB, that's large enough to cause noticeable delays in handling urgent traffic. If you go even larger, the delays can become untenable unless you are certain of your operational conditions.
 
 In order to resolve this issue, a new system of **stream schedulers** (usually referred to as the "SCTP ndata specification") has been designed to make it possible to interleave messages sent on different streams, including streams used to implement WebRTC data channels. This [proposal](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-sctp-ndata) is still in IETF draft form, but once implemented, it will make it possible to send messages with essentially no size limitations, since the SCTP layer will automatically interleave the underlying sub-messages to ensure that every channel's data has the opportunity to get through.
 
-Firefox support for ndata is in the process of being implemented; see [Firefox bug 1381145](https://bugzil.la/1381145) to track it becoming available for general use. The Chrome team is tracking their implementation of ndata support in [Chrome Bug 5696](https://bugs.chromium.org/p/webrtc/issues/detail?id=5696).
+Firefox support for ndata is in the process of being implemented; see [Firefox bug 1381145](https://bugzil.la/1381145) to track it becoming available for general use. The Chrome team is tracking their implementation of ndata support in [Chrome Bug 5696](https://crbug.com/webrtc/5696).
 
 > [!NOTE]
 > Much of the information in this section is based in part on the blog post [Demystifying WebRTC's Data Channel Message Size Limitations](https://lgrahl.de/articles/demystifying-webrtc-dc-size-limit.html), written by Lennart Grahl. He goes into a bit more detail there, but as browsers have been updated since then some of it may be out-of-date. In addition, as time goes by, it will become more so, especially once EOR and ndata support are fully integrated in the major browsers.

files/en-us/web/css/@page/index.md

@@ -408,6 +408,6 @@ Please refer to the various [pseudo-classes](/en-US/docs/Web/CSS/Pseudo-classes)
 
 - The `@page` [`size`](/en-US/docs/Web/CSS/@page/size) descriptor
 - The {{Cssxref("page")}} property
-- See the [\[META\] CSS Paged Media Module Level 3](https://bugzilla.mozilla.org/show_bug.cgi?id=286443) ticket in Bugzilla for tracking progress on the subject (page-based counters, etc.)
+- See the [\[META\] CSS Paged Media Module Level 3](https://bugzil.la/286443) ticket in Bugzilla for tracking progress on the subject (page-based counters, etc.)
 - [CSS paged media](/en-US/docs/Web/CSS/CSS_paged_media) module
 - [Paged.js: W3C paged media polyfill](https://pagedjs.org/documentation/1-the-big-picture/)

files/en-us/web/http/headers/content-security-policy/default-src/index.md

@@ -95,7 +95,7 @@ However, there is a problem here. If you are embedding SVG sprites defined in ex
 </svg>
 ```
 
-your SVG images will be blocked in Firefox if you have a `default-src 'none'` policy set. Firefox does not treat the SVG as an embedded image like other browsers do, therefore `img-src 'self'` will not allow them to be loaded. You need to use `default-src 'self'` if you want your external sprites to load in Firefox (see [bug 1773976](https://bugzilla.mozilla.org/show_bug.cgi?id=1773976) and [this CSP spec issue](https://github.com/w3c/webappsec-csp/issues/199) for more information).
+your SVG images will be blocked in Firefox if you have a `default-src 'none'` policy set. Firefox does not treat the SVG as an embedded image like other browsers do, therefore `img-src 'self'` will not allow them to be loaded. You need to use `default-src 'self'` if you want your external sprites to load in Firefox (see [bug 1773976](https://bugzil.la/1773976) and [this CSP spec issue](https://github.com/w3c/webappsec-csp/issues/199) for more information).
 
 Alternatively, if the `default-src 'none'` policy is a hard requirement, you can include the SVG sprites inline in the HTML page:
 

files/en-us/web/media/formats/containers/index.md

@@ -660,7 +660,7 @@ You can also [add the `codecs` parameter](/en-US/docs/Web/Media/Formats/codecs_p
 </table>
 
 > [!WARNING]
-> Ogg Opus audio files longer than 12h 35m 39s are truncated and exhibit seeking issues when played on Firefox Linux 64 bit ([Firefox bug 1810378](https://bugzilla.mozilla.org/show_bug.cgi?id=1810378)).
+> Ogg Opus audio files longer than 12h 35m 39s are truncated and exhibit seeking issues when played on Firefox Linux 64 bit ([Firefox bug 1810378](https://bugzil.la/1810378)).
 
 ### QuickTime
 

files/en-us/web/security/practical_implementation_guides/csp/index.md

@@ -65,7 +65,7 @@ Keep the following points in mind:
   </svg>
   ```
 
-  your SVG images will be blocked in Firefox if you have a `default-src 'none'` policy set. Firefox does not treat the SVG as an embedded image like other browsers do, therefore `img-src 'self'` will not allow them to be loaded. You need to use `default-src 'self'` if you want your external sprites to load in Firefox (see [bug 1773976](https://bugzilla.mozilla.org/show_bug.cgi?id=1773976) and [this CSP spec issue](https://github.com/w3c/webappsec-csp/issues/199) for more information).
+  your SVG images will be blocked in Firefox if you have a `default-src 'none'` policy set. Firefox does not treat the SVG as an embedded image like other browsers do, therefore `img-src 'self'` will not allow them to be loaded. You need to use `default-src 'self'` if you want your external sprites to load in Firefox (see [bug 1773976](https://bugzil.la/1773976) and [this CSP spec issue](https://github.com/w3c/webappsec-csp/issues/199) for more information).
 
   Alternatively, if the `default-src 'none'` policy is a hard requirement, you can include the SVG sprites inline in the HTML page — see [CSP: default-src](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src#firefox_default-src_none_svg_sprite_blocking_issue) for an example.