microsoft · Skn0tt · Oct 14, 2024 · Oct 14, 2024 · Oct 14, 2024
diff --git a/dotnet/docs/other-locators.mdx b/dotnet/docs/other-locators.mdx
@@ -10,7 +10,7 @@ import HTMLCard from '@site/src/components/HTMLCard';
 
 :::note
 
-Check out the main [locators guide](./locators) for most common and recommended locators.
+Check out the main [locators guide](./locators.mdx) for most common and recommended locators.
 :::
 
 In addition to recommended locators like [Page.GetByRole()](/api/class-page.mdx#page-get-by-role) and [Page.GetByText()](/api/class-page.mdx#page-get-by-text), Playwright supports a variety of other locators described in this guide.

diff --git a/dotnet/docs/release-notes.mdx b/dotnet/docs/release-notes.mdx
@@ -750,7 +750,7 @@ This version was also tested against the following stable channels:
 
 ### New .runsettings file support
 
-`Microsoft.Playwright.NUnit` and `Microsoft.Playwright.MSTest` will now consider the `.runsettings` file and passed settings via the CLI when running end-to-end tests. See in the [documentation](./test-runners) for a full list of supported settings.
+`Microsoft.Playwright.NUnit` and `Microsoft.Playwright.MSTest` will now consider the `.runsettings` file and passed settings via the CLI when running end-to-end tests. See in the [documentation](./test-runners.mdx) for a full list of supported settings.
 
 The following does now work:
 
@@ -811,7 +811,7 @@ Linux support looks like this:
 
 ### New introduction docs
 
-We rewrote our Getting Started docs to be more end-to-end testing focused. Check them out on [playwright.dev](./intro).
+We rewrote our Getting Started docs to be more end-to-end testing focused. Check them out on [playwright.dev](./intro.mdx).
 
 ## Version 1.23
 
@@ -835,7 +835,7 @@ Console.WriteLine(await response.TextAsync());
 Console.WriteLine((await response.JsonAsync())?.GetProperty("foo").GetString());
 ```
 
-Read more about it in our [API testing guide](./api-testing).
+Read more about it in our [API testing guide](./api-testing.mdx).
 
 ### Network Replay
 
@@ -963,7 +963,7 @@ Note that the new methods [Page.RouteFromHARAsync()](/api/class-page.mdx#page-ro
   Read more in [our documentation](./locators.mdx#locate-by-role).
 - New `scale` option in [Page.ScreenshotAsync()](/api/class-page.mdx#page-screenshot) for smaller sized screenshots.
 - New `caret` option in [Page.ScreenshotAsync()](/api/class-page.mdx#page-screenshot) to control text caret. Defaults to `"hide"`.
-- We now ship a designated .NET docker image `mcr.microsoft.com/playwright/dotnet`. Read more in [our documentation](./docker).
+- We now ship a designated .NET docker image `mcr.microsoft.com/playwright/dotnet`. Read more in [our documentation](./docker.mdx).
 
 ### Behavior Changes
 - Playwright now supports large file uploads (100s of MBs) via [Locator.SetInputFilesAsync()](/api/class-locator.mdx#locator-set-input-files) API.
@@ -981,7 +981,7 @@ This version was also tested against the following stable channels:
 
 ### Web-First Assertions
 
-Playwright for .NET 1.20 introduces [Web-First Assertions](./test-assertions).
+Playwright for .NET 1.20 introduces [Web-First Assertions](./test-assertions.mdx).
 
 Consider the following example:
 
@@ -1005,7 +1005,7 @@ public class ExampleTests : PageTest
 
 Playwright will be re-testing the node with the selector `.status` until fetched Node has the `"Submitted"` text. It will be re-fetching the node and checking it over and over, until the condition is met or until the timeout is reached. You can pass this timeout as an option.
 
-Read more in [our documentation](./test-assertions).
+Read more in [our documentation](./test-assertions.mdx).
 
 ### Other Updates
 - New options for methods [Page.ScreenshotAsync()](/api/class-page.mdx#page-screenshot), [Locator.ScreenshotAsync()](/api/class-locator.mdx#locator-screenshot) and [ElementHandle.ScreenshotAsync()](/api/class-elementhandle.mdx#element-handle-screenshot):
@@ -1140,7 +1140,7 @@ Read more about [Locator.WaitForAsync()](/api/class-locator.mdx#locator-wait-for
 - run trace viewer with `pwsh bin/Debug/netX/playwright.ps1 show-trace` and drop trace files to the trace viewer PWA
 - better visual attribution of action targets
 
-Read more about [Trace Viewer](./trace-viewer).
+Read more about [Trace Viewer](./trace-viewer.mdx).
 
 ### Browser Versions
 - Chromium 97.0.4666.0

diff --git a/dotnet/docs/webview2.mdx b/dotnet/docs/webview2.mdx
@@ -138,7 +138,7 @@ public class ExampleTest : WebView2Test
 
 Inside your webview2 control, you can just right-click to open the context menu and select "Inspect" to open the DevTools or press <kbd>F12</kbd>. You can also use the [WebView2.CoreWebView2.OpenDevToolsWindow](https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.opendevtoolswindow?view=webview2-dotnet-1.0.1462.37) method to open the DevTools programmatically.
 
-For debugging tests, see the Playwright [Debugging guide](./debug).
+For debugging tests, see the Playwright [Debugging guide](./debug.mdx).
 
 
 [Accessibility]: /api/class-accessibility.mdx "Accessibility"

diff --git a/dotnet/docs/writing-tests.mdx b/dotnet/docs/writing-tests.mdx
@@ -160,7 +160,7 @@ This is the list of the most popular Playwright actions. Note that there are man
 
 ## Assertions
 
-Playwright provides an async function called [Expect](./test-assertions) to assert and wait until the expected condition is met.
+Playwright provides an async function called [Expect](./test-assertions.mdx) to assert and wait until the expected condition is met.
 
 ```csharp
 await Expect(Page).ToHaveTitleAsync(new Regex("Playwright"));

diff --git a/dotnet/docusaurus.config.ts b/dotnet/docusaurus.config.ts
@@ -216,7 +216,7 @@ export default {
   customFields: {
     repositoryName: "playwright-dotnet",
   },
-  trailingSlash: false,
+  trailingSlash: true,
   webpack: {
     jsLoader: (isServer) => ({
       loader: require.resolve('swc-loader'),

diff --git a/java/docs/api/class-browser.mdx b/java/docs/api/class-browser.mdx
@@ -588,7 +588,7 @@ Browser.newPage(options);
 
 :::note
 
-This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing).
+This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing.mdx).
 :::
 
 You can use [Browser.startTracing()](/api/class-browser.mdx#browser-start-tracing) and [Browser.stopTracing()](/api/class-browser.mdx#browser-stop-tracing) to create a trace file that can be opened in Chrome DevTools performance panel.
@@ -628,7 +628,7 @@ browser.stopTracing();
 
 :::note
 
-This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing).
+This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing.mdx).
 :::
 
 Returns the buffer with trace data.

diff --git a/java/docs/junit.mdx b/java/docs/junit.mdx
@@ -76,7 +76,7 @@ Here is a list of the pre-defined fixtures:
 |browserContext|[BrowserContext]   |Isolated context for this test run. The `page` fixture belongs to this context as well.|
 |browser       |[Browser]          |Browsers are shared across tests to optimize resources.|
 |playwright    |[Playwright]       |Playwright instance is shared between tests running on the same thread.|
-|request       |[APIRequestContext]|Isolated APIRequestContext for this test run. Learn how to do [API testing](./api-testing).|
+|request       |[APIRequestContext]|Isolated APIRequestContext for this test run. Learn how to do [API testing](./api-testing.mdx).|
 
 ## Customizing options
 

diff --git a/java/docs/other-locators.mdx b/java/docs/other-locators.mdx
@@ -10,7 +10,7 @@ import HTMLCard from '@site/src/components/HTMLCard';
 
 :::note
 
-Check out the main [locators guide](./locators) for most common and recommended locators.
+Check out the main [locators guide](./locators.mdx) for most common and recommended locators.
 :::
 
 In addition to recommended locators like [Page.getByRole()](/api/class-page.mdx#page-get-by-role) and [Page.getByText()](/api/class-page.mdx#page-get-by-text), Playwright supports a variety of other locators described in this guide.

diff --git a/java/docs/release-notes.mdx b/java/docs/release-notes.mdx
@@ -999,7 +999,7 @@ This version was also tested against the following stable channels:
 - New options for methods [Page.screenshot()](/api/class-page.mdx#page-screenshot), [Locator.screenshot()](/api/class-locator.mdx#locator-screenshot) and [ElementHandle.screenshot()](/api/class-elementhandle.mdx#element-handle-screenshot):
   * Option `ScreenshotAnimations.DISABLED` rewinds all CSS animations and transitions to a consistent state
   * Option `mask: Locator[]` masks given elements, overlaying them with pink `#FF00FF` boxes.
-- [Trace Viewer](./trace-viewer) now shows [API testing requests](./api-testing).
+- [Trace Viewer](./trace-viewer.mdx) now shows [API testing requests](./api-testing.mdx).
 - [Locator.highlight()](/api/class-locator.mdx#locator-highlight) visually reveals element(s) for easier debugging.
 
 ### Announcements
@@ -1053,11 +1053,11 @@ To do a request on behalf of Playwright's Page, use **new [Page.request()](/api/
 APIResponse res = page.request().get("http://example.com/foo.json");
 ```
 
-Read more about it in our [API testing guide](./api-testing).
+Read more about it in our [API testing guide](./api-testing.mdx).
 
 ### Web-First Assertions
 
-Playwright for Java 1.18 introduces [Web-First Assertions](./test-assertions).
+Playwright for Java 1.18 introduces [Web-First Assertions](./test-assertions.mdx).
 
 Consider the following example:
 
@@ -1076,7 +1076,7 @@ public class TestExample {
 
 Playwright will be re-testing the node with the selector `.status` until fetched Node has the `"Submitted"` text. It will be re-fetching the node and checking it over and over, until the condition is met or until the timeout is reached. You can pass this timeout as an option.
 
-Read more in [our documentation](./test-assertions).
+Read more in [our documentation](./test-assertions.mdx).
 
 ### Locator Improvements
 - [Locator.dragTo()](/api/class-locator.mdx#locator-drag-to)
@@ -1173,7 +1173,7 @@ Read more about [Locator.waitFor()](/api/class-locator.mdx#locator-wait-for).
 - run trace viewer with `mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args="show-trace"` and drop trace files to the trace viewer PWA
 - better visual attribution of action targets
 
-Read more about [Trace Viewer](./trace-viewer).
+Read more about [Trace Viewer](./trace-viewer.mdx).
 
 ### Browser Versions
 - Chromium 97.0.4666.0
@@ -1387,7 +1387,7 @@ This version of Playwright was also tested against the following stable channels
 
 ## Version 1.10
 - [Playwright for Java v1.10](https://github.com/microsoft/playwright-java) is **now stable**!
-- Run Playwright against **Google Chrome** and **Microsoft Edge** stable channels with the [new channels API](./browsers).
+- Run Playwright against **Google Chrome** and **Microsoft Edge** stable channels with the [new channels API](./browsers.mdx).
 - Chromium screenshots are **fast** on Mac & Windows.
 
 #### Bundled Browser Versions
@@ -1400,7 +1400,7 @@ This version of Playwright was also tested against the following stable channels
 - Microsoft Edge 89
 
 #### New APIs
-- [BrowserType.launch()](/api/class-browsertype.mdx#browser-type-launch) now accepts the new `'channel'` option. Read more in [our documentation](./browsers).
+- [BrowserType.launch()](/api/class-browsertype.mdx#browser-type-launch) now accepts the new `'channel'` option. Read more in [our documentation](./browsers.mdx).
 
 ## Version 1.9
 - [Playwright Inspector](./debug.mdx) is a **new GUI tool** to author and debug your tests.

diff --git a/java/docs/webview2.mdx b/java/docs/webview2.mdx
@@ -174,7 +174,7 @@ public class TestExample {
 
 Inside your webview2 control, you can just right-click to open the context menu and select "Inspect" to open the DevTools or press <kbd>F12</kbd>. You can also use the [WebView2.CoreWebView2.OpenDevToolsWindow](https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.opendevtoolswindow?view=webview2-dotnet-1.0.1462.37) method to open the DevTools programmatically.
 
-For debugging tests, see the Playwright [Debugging guide](./debug).
+For debugging tests, see the Playwright [Debugging guide](./debug.mdx).
 
 
 [APIRequest]: /api/class-apirequest.mdx "APIRequest"

diff --git a/java/docusaurus.config.ts b/java/docusaurus.config.ts
@@ -216,7 +216,7 @@ module.exports = {
   customFields: {
     repositoryName: "playwright-java",
   },
-  trailingSlash: false,
+  trailingSlash: true,
   webpack: {
     jsLoader: (isServer) => ({
       loader: require.resolve('swc-loader'),

diff --git a/nodejs/docs/accessibility-testing.mdx b/nodejs/docs/accessibility-testing.mdx
@@ -37,7 +37,7 @@ This example demonstrates how to test an entire page for automatically detectabl
 1. Uses normal Playwright Test syntax to define a test case
 1. Uses normal Playwright syntax to navigate to the page under test
 1. Awaits `AxeBuilder.analyze()` to run the accessibility scan against the page
-1. Uses normal Playwright Test [assertions](./test-assertions) to verify that there are no violations in the returned scan results
+1. Uses normal Playwright Test [assertions](./test-assertions.mdx) to verify that there are no violations in the returned scan results
 
 <Tabs
   groupId="js-flavor"
@@ -220,7 +220,7 @@ function violationFingerprints(accessibilityScanResults) {
 
 Most accessibility tests are primarily concerned with the `violations` property of the axe scan results. However, the scan results contain more than just `violations`. For example, the results also contain information about rules which passed and about elements which axe found to have inconclusive results for some rules. This information can be useful for debugging tests that aren't detecting all the violations you expect them to.
 
-To include *all* of the scan results as part of your test results for debugging purposes, you can add the scan results as a test attachment with [`testInfo.attach()`](./api/class-testinfo#test-info-attach). [Reporters](./test-reporters) can then embed or link the full results as part of your test output.
+To include *all* of the scan results as part of your test results for debugging purposes, you can add the scan results as a test attachment with [`testInfo.attach()`](./api/class-testinfo#test-info-attach). [Reporters](./test-reporters.mdx) can then embed or link the full results as part of your test output.
 
 The following example demonstrates attaching scan results to a test:
 
@@ -241,7 +241,7 @@ test('example with attachment', async ({ page }, testInfo) => {
 
 ## Using a test fixture for common axe configuration
 
-[Test fixtures](./test-fixtures) are a good way to share common `AxeBuilder` configuration across many tests. Some scenarios where this might be useful include:
+[Test fixtures](./test-fixtures.mdx) are a good way to share common `AxeBuilder` configuration across many tests. Some scenarios where this might be useful include:
 * Using a common set of rules among all of your tests
 * Suppressing a known violation in a common element which appears in many different pages
 * Attaching standalone accessibility reports consistently for many scans

diff --git a/nodejs/docs/api/class-browser.mdx b/nodejs/docs/api/class-browser.mdx
@@ -750,7 +750,7 @@ await browser.removeAllListeners(type, options);
 
 :::note
 
-This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing).
+This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing.mdx).
 :::
 
 You can use [browser.startTracing()](/api/class-browser.mdx#browser-start-tracing) and [browser.stopTracing()](/api/class-browser.mdx#browser-stop-tracing) to create a trace file that can be opened in Chrome DevTools performance panel.
@@ -789,7 +789,7 @@ await browser.stopTracing();
 
 :::note
 
-This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing).
+This API controls [Chromium Tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) which is a low-level chromium-specific debugging tool. API to control [Playwright Tracing](../trace-viewer) could be found [here](./class-tracing.mdx).
 :::
 
 Returns the buffer with trace data.

diff --git a/nodejs/docs/api/class-page.mdx b/nodejs/docs/api/class-page.mdx
@@ -2360,7 +2360,7 @@ page.clock
 Only available for Chromium atm.
 :::
 
-Browser-specific Coverage implementation. See [Coverage](./class-coverage) for more details.
+Browser-specific Coverage implementation. See [Coverage](./class-coverage.mdx) for more details.
 
 **Usage**
 

diff --git a/nodejs/docs/best-practices.mdx b/nodejs/docs/best-practices.mdx
@@ -337,8 +337,8 @@ Playwright comes with a range of tooling to help you write tests.
 - The [VS Code extension](./getting-started-vscode.mdx) gives you a great developer experience when writing, running, and debugging tests.
 - The [test generator](./codegen.mdx) can generate tests and pick locators for you.
 - The [trace viewer](./trace-viewer.mdx) gives you a full trace of your tests as a local PWA that can easily be shared. With the trace viewer you can view the timeline, inspect DOM snapshots for each action, view network requests and more.
-- The [UI Mode](./test-ui-mode) lets you explore, run and debug tests with a time travel experience complete with watch mode. All test files are loaded into the testing sidebar where you can expand each file and describe block to individually run, view, watch and debug each test.
-- [TypeScript](./test-typescript) in Playwright works out of the box and gives you better IDE integrations. Your IDE will show you everything you can do and highlight when you do something wrong. No TypeScript experience is needed and it is not necessary for your code to be in TypeScript, all you need to do is create your tests with a `.ts` extension.
+- The [UI Mode](./test-ui-mode.mdx) lets you explore, run and debug tests with a time travel experience complete with watch mode. All test files are loaded into the testing sidebar where you can expand each file and describe block to individually run, view, watch and debug each test.
+- [TypeScript](./test-typescript.mdx) in Playwright works out of the box and gives you better IDE integrations. Your IDE will show you everything you can do and highlight when you do something wrong. No TypeScript experience is needed and it is not necessary for your code to be in TypeScript, all you need to do is create your tests with a `.ts` extension.
 
 ### Test across all browsers
 

diff --git a/nodejs/docs/browsers.mdx b/nodejs/docs/browsers.mdx
@@ -79,7 +79,7 @@ Playwright can run tests on Chromium, WebKit and Firefox browsers as well as bra
 
 ### Run tests on different browsers
 
-Playwright can run your tests in multiple browsers and configurations by setting up **projects** in the config. You can also add [different options](./test-configuration) for each project.
+Playwright can run your tests in multiple browsers and configurations by setting up **projects** in the config. You can also add [different options](./test-configuration.mdx) for each project.
 
 ```js
 import { defineConfig, devices } from '@playwright/test';

diff --git a/nodejs/docs/ci.mdx b/nodejs/docs/ci.mdx
@@ -83,7 +83,7 @@ jobs:
 
 #### On push/pull_request (sharded)
 
-GitHub Actions supports [sharding tests between multiple jobs](https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs). Check out our [sharding doc](./test-sharding) to learn more about sharding and to see a [GitHub actions example](./test-sharding.mdx#github-actions-example) of how to configure a job to run your tests on multiple machines as well as how to merge the HTML reports.
+GitHub Actions supports [sharding tests between multiple jobs](https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs). Check out our [sharding doc](./test-sharding.mdx) to learn more about sharding and to see a [GitHub actions example](./test-sharding.mdx#github-actions-example) of how to configure a job to run your tests on multiple machines as well as how to merge the HTML reports.
 
 #### Via Containers