MicrosoftDocs · captainbrosset · Oct 1, 2025 · Oct 1, 2025 · Oct 1, 2025
diff --git a/.github/workflows/webplat-relnotes.yaml b/.github/workflows/webplat-relnotes.yaml
@@ -30,19 +30,4 @@ jobs:
       - name: Generate release notes
         run: |
           cd scripts
-          token=${{ secrets.GITHUB_TOKEN }} node web-platform-release-notes.js
-
-      - name: Commit changes if needed
-        run: |
-          files=$(git ls-files --others --exclude-standard)
-          if [ -n "$files" ]; then
-              echo "Committing the new release notes file."
-              git config --local user.email "${{ github.actor }}@users.noreply.github.com"
-              git config --local user.name "${{ github.actor }}"
-              git checkout -b web-platform-release-notes
-              git add .
-              git commit -m "New beta web platform release notes"
-              git push origin web-platform-release-notes
-          else
-              echo "No new files to add."
-          fi
+          actor=${{ github.actor }} token=${{ secrets.GITHUB_TOKEN }} node web-platform-release-notes.js
diff --git a/microsoft-edge/dev-videos/index.md b/microsoft-edge/dev-videos/index.md
@@ -685,8 +685,7 @@ The Microsoft Edge team specified and implemented the new EyeDropper API in coll
 Many creative applications enable users to pick colors from parts of an app window or even from the entire screen, typically using an eyedropper metaphor. The EyeDropper API enables authors to use a browser-supplied eyedropper in the construction of custom color pickers on the web.
 
 See also:
-* [Picking colors of any pixel on the screen with the EyeDropper API | web.dev](https://web.dev/eyedropper/)
-* [EyeDropper API - Web APIs | MDN developer.mozilla.org](https://developer.mozilla.org/docs/Web/API/EyeDropper_API)
+* [EyeDropper API](https://developer.mozilla.org/docs/Web/API/EyeDropper_API) at MDN.
 * [EyeDropper API demos](https://github.com/MicrosoftEdge/Demos/tree/main/eyedropper)
 
 

diff --git a/microsoft-edge/devtools/device-mode/testing-other-browsers.md b/microsoft-edge/devtools/device-mode/testing-other-browsers.md
@@ -49,9 +49,9 @@ Browser emulators don't emulate differences in web API support or CSS support.
 
 Here are some browser emulators you can use to test your website on other browsers:
 
-* [Firefox Responsive Design Mode](https://firefox-source-docs.mozilla.org/devtools-user/responsive_design_mode/index.html).
-* [Chrome Device Mode](https://developer.chrome.com/docs/devtools/device-mode).
-* [Safari Responsive Design Mode](https://developer.apple.com/documentation/safari-developer-tools/responsive-design-mode).
+* [Firefox Responsive Design Mode](https://firefox-source-docs.mozilla.org/devtools-user/responsive_design_mode/index.html)
+* [Chrome Device Mode](https://developer.chrome.com/docs/devtools/device-mode)
+* [Safari Responsive Design Mode](https://developer.apple.com/documentation/safari-developer-tools/responsive-design-mode)
 
 
 <!-- ====================================================================== -->

diff --git a/microsoft-edge/devtools/javascript/background-services.md b/microsoft-edge/devtools/javascript/background-services.md
@@ -109,9 +109,13 @@ After a **service worker** has received a [Push Message](https://developer.mozil
 <!-- ====================================================================== -->
 ## Payment Handler
 
-The [Payment Handler API](https://web.dev/web-based-payment-apps-overview/) allows web applications to handle payment requests on behalf of users. To log the payment request and response events for 3 days, even when DevTools isn't open:
+The Payment Handler API allows web applications to handle payment requests on behalf of users.  See [Payment Handler API](https://developer.mozilla.org/docs/Web/API/Payment_Handler_API) at MDN.
 
-1. Open DevTools by right-clicking the webpage and selecting **Inspect**.  Or by pressing **Ctrl+Shift+I** (Windows, Linux) or **Command+Option+I** (macOS).
+To log the payment request and response events for 3 days, even when DevTools isn't open:
+
+1. Right-click the webpage, and then select **Inspect**.  DevTools opens.
+
+   Or, press **Ctrl+Shift+I** (Windows, Linux) or **Command+Option+I** (macOS).
 
 1. In DevTools, on the main toolbar, select the **Application** tab.  If that tab isn't visible, click the **More tabs** (![More tabs icon](./background-services-images/more-tabs-icon-light-theme.png)) button, or else the **More Tools** (![More Tools icon](./background-services-images/more-tools-icon-light-theme.png)) button.
 

diff --git a/microsoft-edge/devtools/javascript/guides/mark-content-scripts-library-code.md b/microsoft-edge/devtools/javascript/guides/mark-content-scripts-library-code.md
@@ -45,7 +45,10 @@ To avoid pausing on extension code:
 ## See also
 
 * [Step 4: Step through the code](../index.md#step-4-step-through-the-code) in _Get started debugging JavaScript_
-* [Content scripts](https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts) in Chrome Extensions docs.
+* [Content scripts](https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/Content_scripts) at MDN.
+<!-- 
+* [Sample: Picture inserter using content script](../../../extensions/getting-started/picture-inserter-content-script.md)
+-->
 
 
 <!-- ====================================================================== -->

diff --git a/microsoft-edge/devtools/performance/index.md b/microsoft-edge/devtools/performance/index.md
@@ -26,10 +26,12 @@ ms.date: 09/04/2023
 
 _Runtime performance_ is how your page performs when it's running, as opposed to loading.  The following tutorial teaches you how to use the DevTools **Performance** tool to analyze runtime performance.
 
-The skills you learn in this tutorial are useful for analyzing loading, interactivity, and visual stability of your web content, which are also key indicators for [Core Web Vitals](https://web.dev/vitals/).  Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.  You can see these Core Web Vitals in the **Performance** tool.
+The skills you learn in this tutorial are useful for analyzing loading, interactivity, and visual stability of your web content, which are also key indicators for Core Web Vitals.  Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.  You can see these Core Web Vitals in the **Performance** tool.
 
 See also:
-- [Optimize website speed using Lighthouse](../speed/get-started.md)
+* [Web Vitals](https://web.dev/articles/vitals)<!-- web.dev link ok, only doc'd there --> at web.dev.
+* [Terminology](./overview.md#terminology) in _Performance tool: Analyze your website's performance_.
+* [Optimize website speed using Lighthouse](../speed/get-started.md)
 
 
 <!-- ====================================================================== -->
@@ -184,9 +186,9 @@ Continuing from above:
    ![The line of code that caused the forced layout](./index-images/sources-app-update.png)
 
    The problem with the unoptimized code is that, in each animation frame, it changes the style for each icon, and then queries the position of each icon on the page. Because the styles changed, the browser doesn't know if each icon position changed, so it has to re-layout the icon in order to compute the new position.
-   <!--
-   > To learn more, see [Avoid forced synchronous layouts](https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/#avoid-forced-synchronous-layouts).
-   -->
+
+   See also:
+   * [Avoid forced synchronous layouts](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing#avoid_forced_synchronous_layouts)<!-- web.dev link ok, no perf doc'n at mdn --> in _Avoid large, complex layouts and layout thrashing_ at web.dev.
 
 
 <!-- ------------------------------ -->
@@ -267,15 +269,14 @@ We then adjust the direction of the icon, but this time we don't read `element.o
 
 Finally, we set the new position of the icon, but this time we use `element.style.transform` instead of `element.style.top`. Using `element.style.transform` is faster, because the CSS `transform` property can be applied by the browser rendering engine without having to recalculate the layout of the page. When using the `transform` property, the browser considers each icon as an individual layer, and then displays these layers in the correct positions by re-compositing the final image.
 
-To learn more, see [Use transform and opacity changes for animations](https://web.dev/stick-to-compositor-only-properties-and-manage-layer-count/#use-transform-and-opacity-changes-for-animations).
+See also:
+* [Avoid properties that trigger layout or paint](https://web.dev/articles/animations-guide#triggers)<!-- web.dev link ok, not doc'd at mdn --> in _How to create high-performance CSS animations_ at web.dev.
+* [Transitioning opacity](https://developer.mozilla.org/docs/Web/CSS/opacity#transitioning_opacity) in _opacity_ at MDN.
 
 
 <!-- ====================================================================== -->
 ## Next steps
 
-<!--The foundation for understanding performance is the RAIL model.  The RAIL model teaches you the performance metrics that are most important to your users.
-To learn more, see [Measure Performance With The RAIL Model](https://web.dev/rail/). -->
-
 To get more comfortable with the **Performance** tool, practice profiling your pages and analyzing the results.
 
 If you have any questions about your results, in the **Activity Bar**, select **Help** (![the Help icon in the Activity Bar](./index-images/help-icon.png)) > **Feedback**.  Or, press **Alt+Shift+I** (Windows, Linux) or **Option+Shift+I** (macOS).
@@ -284,16 +285,7 @@ Or, [file an issue on the MicrosoftEdge / DevTools repo](https://github.com/Micr
 
 In your feedback, include screenshots or links to reproducible pages, if possible.
 
-There are many ways to improve runtime performance.  This article focused on one particular animation bottleneck to give you a focused tour of the **Performance** tool, but it's only one of many bottlenecks you may encounter.  <!--  The rest of the Rendering Performance series has a lot of good tips for improving various aspects of runtime performance, such as:  -->
-
-<!--
-* [Optimize JavaScript execution](https://web.dev/optimize-javascript-execution/)
-* [Reduce the scope and complexity of style calculations](https://web.dev/reduce-the-scope-and-complexity-of-style-calculations/)
-* [Avoid large, complex layouts and layout thrashing](https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/)
-* [Simplify paint complexity and reduce paint areas](https://web.dev/simplify-paint-complexity-and-reduce-paint-areas/)
-* [Stick to Compositor-Only Properties and Manage Layer Count](https://web.dev/stick-to-compositor-only-properties-and-manage-layer-count/)
-* [Debounce your input handlers](https://web.dev/debounce-your-input-handlers/)
--->
+There are many ways to improve runtime performance.  This article focused on one particular animation bottleneck to give you a focused tour of the **Performance** tool, but it's only one of many bottlenecks you may encounter.
 
 
 <!-- ====================================================================== -->

diff --git a/microsoft-edge/devtools/performance/overview.md b/microsoft-edge/devtools/performance/overview.md
@@ -23,7 +23,6 @@ ms.date: 03/31/2025
    limitations under the License.  -->
 # Performance tool: Analyze your website's performance
 <!-- https://developer.chrome.com/docs/devtools/performance/overview -->
-<!-- https://microsoftedge.github.io/Demos/exploring-the-universe/ -->
 
 Use the **Performance** tool to analyze your website's performance.  There are two main views:
 
@@ -32,15 +31,11 @@ Use the **Performance** tool to analyze your website's performance.  There are t
 
 **Detailed contents:**
 * [Overview](#overview)
-
    * [Open the Performance tool](#open-the-performance-tool)
       * [Using the Command Menu](#using-the-command-menu)
-
    * [Local metrics for page interactions](#local-metrics-for-page-interactions)
    * [Recorded profile timeline](#recorded-profile-timeline)
    * [Switching to viewing local metrics or another profile](#switching-to-viewing-local-metrics-or-another-profile)
-
-
 * [Monitor Core Web Vitals metrics](#monitor-core-web-vitals-metrics)
    * [Terminology](#terminology)
    * [Use the demo page](#use-the-demo-page)
@@ -50,15 +45,14 @@ Use the **Performance** tool to analyze your website's performance.  There are t
    * [Record a performance profile](#record-a-performance-profile)
    * [Change capture settings](#change-capture-settings)
    * [Analyze a performance report](#analyze-a-performance-report)
-* [Improve performance with these tools](#improve-performance-with-these-tools) -->
+* [Improve performance with these tools](#improve-performance-with-these-tools)
 
 For a walkthrough of using the **Performance** tool to improve your website's performance, see [Analyze runtime performance (tutorial)](./index.md).
 
 
 <!-- ====================================================================== -->
 ## Overview
 <!-- https://developer.chrome.com/docs/devtools/performance/overview#overview -->
-<!-- https://microsoftedge.github.io/Demos/exploring-the-universe/ -->
 <!-- covers basic nav between the two states, and what to use them for, not how to use either view -->
 
 The **Performance** tool displays local metrics for page interactions, and lets you record CPU performance profiles of your web applications.  Analyze profiles to find potential performance bottlenecks and ways that you can optimize resource use.
@@ -159,14 +153,15 @@ Use the **Performance** tool to view Core Web Vitals metrics in the initial, **L
 
 <!-- ---------------------------------- -->
 #### Terminology
+<!-- not in upstream -->
 
 | Term | Description | Docs |
 |---|---|---|
-| Web Vitals | A large set of metrics giving unified guidance to delivering a great user experience on the web. | [Web Vitals](https://web.dev/articles/vitals) |
-| Core Web Vitals | The subset of Web Vitals that apply to all web pages, and should be measured by all site owners.  Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome. | [Core Web Vitals](https://web.dev/articles/vitals#core-web-vitals) in _Web Vitals_ |
-| Largest Contentful Paint (LCP) | Measures _loading_ performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.  The render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. | [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp), [Optimize LCP](https://web.dev/articles/optimize-lcp) |
-| Cumulative Layout Shift (CLS) | Measures _visual stability_. To provide a good user experience, pages should maintain a CLS of 0.1. or less.  The largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page. | [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls), [Optimize CLS](https://web.dev/articles/optimize-cls) |
-| Interaction to Next Paint (INP) | Measures _interactivity_. To provide a good user experience, pages should have a INP of 200 milliseconds or less.  The page's overall responsiveness to user interactions, based on the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. | [Interaction to Next Paint (INP)](https://web.dev/articles/inp), [Optimize INP](https://web.dev/articles/optimize-inp) |
+| Web Vitals | A large set of metrics giving unified guidance to delivering a great user experience on the web. | [Web Vitals](https://web.dev/articles/vitals)<!-- web.dev link ok, cwv not doc'd at mdn --> at web.dev. |
+| Core Web Vitals | The subset of Web Vitals that apply to all web pages, and should be measured by all site owners.  Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome. | [Core Web Vitals](https://web.dev/articles/vitals#core-web-vitals)<!-- web.dev link ok, cwv not doc'd at mdn --> in _Web Vitals_ at web.dev. |
+| Largest Contentful Paint (LCP) | Measures _loading_ performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.  The render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. | [Largest Contentful Paint (LCP)](https://developer.mozilla.org/docs/Glossary/Largest_contentful_paint) in Glossary at MDN.  [LargestContentfulPaint](https://developer.mozilla.org/docs/Web/API/LargestContentfulPaint) at MDN. |
+| Cumulative Layout Shift (CLS) | Measures _visual stability_. To provide a good user experience, pages should maintain a CLS of 0.1. or less.  The largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page. | [Cumulative Layout Shift (CLS)](https://developer.mozilla.org/docs/Glossary/CLS) in Glossary at MDN.  [LayoutShift](https://developer.mozilla.org/docs/Web/API/LayoutShift) at MDN. |
+| Interaction to Next Paint (INP) | Measures _interactivity_. To provide a good user experience, pages should have a INP of 200 milliseconds or less.  The page's overall responsiveness to user interactions, based on the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. | [Interaction to Next Paint (INP)](https://developer.mozilla.org/docs/Glossary/Interaction_to_next_paint) in Glossary at MDN.  [PerformanceEventTiming](https://developer.mozilla.org/docs/Web/API/PerformanceEventTiming) at MDN. |
 | local metrics, local data | The LCP, CLS, and INP metrics.  They are captured locally on the inspected webpage, and are updated as you interact with the page. | |
 
 
@@ -177,7 +172,7 @@ To produce a **poor** or **needs improvement** metric on the **LCP**, **CLS**, a
 
 1. Open a webpage, such as the [Exploring the universe](https://microsoftedge.github.io/Demos/exploring-the-universe/) demo, in a new window or tab.
 
-   The [Exploring the universe](https://microsoftedge.github.io/Demos/exploring-the-universe/) demo page is designed to load and handle interactions slowly on purpose, in order to illustrate how the LCP, CLS, and INP metrics can be used in the **Performance** tool to identify and fix performance issues.
+   The "Exploring the universe" demo page is designed to load and handle interactions slowly on purpose, in order to illustrate how the LCP, CLS, and INP metrics can be used in the **Performance** tool to identify and fix performance issues.
 
 1. Right-click the webpage and then select **Inspect**.
 
@@ -366,6 +361,12 @@ Discover other tools that can help you improve your website's performance:
 | **Performance** tool | [View layers information](../performance/reference.md#view-layers-information) in _Performance features reference_ |
 
 
+<!-- ====================================================================== -->
+## See also
+
+* [Exploring the universe](https://microsoftedge.github.io/Demos/exploring-the-universe/) demo page
+
+
 <!-- ====================================================================== -->
 > [!NOTE]
 > Portions of this page are modifications based on work created and [shared by Google](https://developers.google.com/terms/site-policies) and used according to terms described in the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0).