microsoft · playwrightmachine · Nov 23, 2024
diff --git a/dotnet/docs/actionability.mdx b/dotnet/docs/actionability.mdx
@@ -93,11 +93,20 @@ Element is considered stable when it has maintained the same bounding box for at
 
 ## Enabled
 
-Element is considered enabled unless it is a `<button>`, `<select>`, `<input>` or `<textarea>` with a `disabled` property.
+Element is considered enabled when it is **not disabled**.
+
+Element is **disabled** when:
+- it is a `<button>`, `<select>`, `<input>`, `<textarea>`, `<option>` or `<optgroup>` with a `[disabled]` attribute;
+- it is a `<button>`, `<select>`, `<input>`, `<textarea>`, `<option>` or `<optgroup>` that is a part of a `<fieldset>` with a `[disabled]` attribute;
+- it is a descendant of an element with `[aria-disabled=true]` attribute.
 
 ## Editable
 
-Element is considered editable when it is [enabled] and does not have `readonly` property set.
+Element is considered editable when it is [enabled] and is **not readonly**.
+
+Element is **readonly** when:
+- it is a `<select>`, `<input>` or `<textarea>` with a `[readonly]` attribute;
+- it has an `[aria-readonly=true]` attribute and an aria role that [supports it](https://w3c.github.io/aria/#aria-readonly).
 
 ## Receives Events
 

diff --git a/dotnet/docs/api/class-locator.mdx b/dotnet/docs/api/class-locator.mdx
@@ -1492,7 +1492,7 @@ Boolean disabled = await page.GetByRole(AriaRole.Button).IsDisabledAsync();
 
 <font size="2" style={{position: "relative", top: "-20px"}}>Added in: v1.14</font><x-search>locator.IsEditableAsync</x-search>
 
-Returns whether the element is [editable](../actionability.mdx#editable).
+Returns whether the element is [editable](../actionability.mdx#editable). If the target element is not an `<input>`, `<textarea>`, `<select>`, `[contenteditable]` and does not have a role allowing `[aria-readonly]`, this method throws an error.
 
 :::warning[Asserting editable state]
 

diff --git a/dotnet/docs/intro.mdx b/dotnet/docs/intro.mdx
@@ -10,7 +10,7 @@ import HTMLCard from '@site/src/components/HTMLCard';
 
 Playwright was created specifically to accommodate the needs of end-to-end testing. Playwright supports all modern rendering engines including Chromium, WebKit, and Firefox. Test on Windows, Linux, and macOS, locally or on CI, headless or headed with native mobile emulation.
 
-You can choose to use [MSTest base classes](./test-runners.mdx#mstest) or [NUnit base classes](./test-runners.mdx#nunit) that Playwright provides to write end-to-end tests. These classes support running tests on multiple browser engines, parallelizing tests, adjusting launch/context options and getting a [Page]/[BrowserContext] instance per test out of the box. Alternatively you can use the [library](./library.mdx) to manually write the testing infrastructure.
+You can choose to use [MSTest base classes](./test-runners.mdx) or [NUnit base classes](./test-runners.mdx) that Playwright provides to write end-to-end tests. These classes support running tests on multiple browser engines, parallelizing tests, adjusting launch/context options and getting a [Page]/[BrowserContext] instance per test out of the box. Alternatively you can use the [library](./library.mdx) to manually write the testing infrastructure.
 1. Start by creating a new project with `dotnet new`. This will create the `PlaywrightTests` directory which includes a `UnitTest1.cs` file:
 
 <Tabs groupId="test-runners" defaultValue="mstest" values={[ {label: 'MSTest', value: 'mstest'}, {label: 'NUnit', value: 'nunit'}, ] }>

diff --git a/dotnet/docs/languages.mdx b/dotnet/docs/languages.mdx
@@ -30,7 +30,7 @@ You can choose any testing framework such as JUnit or TestNG based on your proje
 
 ## .NET
 
-Playwright for .NET comes with [MSTest base classes](https://playwright.dev/dotnet/docs/test-runners#mstest) and [NUnit base classes](https://playwright.dev/dotnet/docs/test-runners#nunit) for writing end-to-end tests.
+Playwright for .NET comes with [MSTest base classes](https://playwright.dev/dotnet/docs/test-runners) and [NUnit base classes](https://playwright.dev/dotnet/docs/test-runners) for writing end-to-end tests.
 * [Documentation](https://playwright.dev/dotnet/docs/intro)
 * [GitHub repo](https://github.com/microsoft/playwright-dotnet)
 

diff --git a/dotnet/docs/library.mdx b/dotnet/docs/library.mdx
@@ -8,7 +8,7 @@ import HTMLCard from '@site/src/components/HTMLCard';
 
 ## Introduction
 
-Playwright can either be used with the [MSTest](./test-runners.mdx#mstest) or [NUnit](./test-runners.mdx#nunit), or as a Playwright Library (this guide). If you are working on an application that utilizes Playwright capabilities or you are using Playwright with another test runner, read on.
+Playwright can either be used with the [MSTest](./test-runners.mdx) or [NUnit](./test-runners.mdx), or as a Playwright Library (this guide). If you are working on an application that utilizes Playwright capabilities or you are using Playwright with another test runner, read on.
 
 ## Usage
 

diff --git a/dotnet/docs/test-runners.mdx b/dotnet/docs/test-runners.mdx
@@ -8,40 +8,74 @@ import HTMLCard from '@site/src/components/HTMLCard';
 
 ## Introduction
 
-While Playwright for .NET isn't tied to a particular test runner or testing framework, in our experience the easiest way of getting started is by using the base classes we provide for [MSTest](#mstest) and [NUnit](#nunit). These classes support running tests on multiple browser engines, adjusting launch/context options and getting a [Page]/[BrowserContext] instance per test out of the box. 
+While Playwright for .NET isn't tied to a particular test runner or testing framework, in our experience the easiest way of getting started is by using the base classes we provide for MSTest and NUnit. These classes support running tests on multiple browser engines, adjusting launch/context options and getting a [Page]/[BrowserContext] instance per test out of the box. 
 
 Playwright and Browser instances will be reused between tests for better performance. We recommend running each test case in a new BrowserContext, this way browser state will be isolated between the tests.
 
-## MSTest
+<Tabs groupId="test-runners" defaultValue="mstest" values={[ {label: 'MSTest', value: 'mstest'}, {label: 'NUnit', value: 'nunit'}, ] }>
+
+<TabItem value="nunit">
+
+Playwright provides base classes to write tests with NUnit via the [`Microsoft.Playwright.NUnit`](https://www.nuget.org/packages/Microsoft.Playwright.NUnit) package.
+
+</TabItem>
+
+<TabItem value="mstest">
 
 Playwright provides base classes to write tests with MSTest via the [`Microsoft.Playwright.MSTest`](https://www.nuget.org/packages/Microsoft.Playwright.MSTest) package.
 
+</TabItem>
+
+</Tabs>
+
 Check out the [installation guide](./intro.mdx) to get started.
 
-### Running MSTest tests in Parallel
+## Running tests in Parallel
+
+<Tabs groupId="test-runners" defaultValue="mstest" values={[ {label: 'MSTest', value: 'mstest'}, {label: 'NUnit', value: 'nunit'}, ] }>
+
+<TabItem value="nunit">
+
+By default NUnit will run all test files in parallel, while running tests inside each file sequentially (`ParallelScope.Self`). It will create as many processes as there are cores on the host system. You can adjust this behavior using the NUnit.NumberOfTestWorkers parameter. Only `ParallelScope.Self` is supported.
+
+For CPU-bound tests, we recommend using as many workers as there are cores on your system, divided by 2. For IO-bound tests you can use as many workers as you have cores.
+
+```bash
+dotnet test -- NUnit.NumberOfTestWorkers=5
+```
+
+</TabItem>
+
+<TabItem value="mstest">
 
 By default MSTest will run all classes in parallel, while running tests inside each class sequentially (`ExecutionScope.ClassLevel`). It will create as many processes as there are cores on the host system. You can adjust this behavior by using the following CLI parameter or using a `.runsettings` file, see below. Running tests in parallel at the method level (`ExecutionScope.MethodLevel`) is not supported.
 
 ```bash
 dotnet test --settings:.runsettings -- MSTest.Parallelize.Workers=4
 ```
 
-### Customizing [BrowserContext] options
+</TabItem>
+
+</Tabs>
+
+## Customizing [BrowserContext] options
+
+<Tabs groupId="test-runners" defaultValue="mstest" values={[ {label: 'MSTest', value: 'mstest'}, {label: 'NUnit', value: 'nunit'}, ] }>
+
+<TabItem value="nunit">
 
 To customize context options, you can override the `ContextOptions` method of your test class derived from `Microsoft.Playwright.MSTest.PageTest` or `Microsoft.Playwright.MSTest.ContextTest`. See the following example:
 
 ```csharp
-using System.Threading.Tasks;
-using Microsoft.Playwright;
-using Microsoft.Playwright.MSTest;
-using Microsoft.VisualStudio.TestTools.UnitTesting;
+using Microsoft.Playwright.NUnit;
 
 namespace PlaywrightTests;
 
-[TestClass]
-public class ExampleTest : PageTest
+[Parallelizable(ParallelScope.Self)]
+[TestFixture]
+public class MyTest : PageTest
 {
-    [TestMethod]
+    [Test]
     public async Task TestWithCustomContextOptions()
     {
         // The following Page (and BrowserContext) instance has the custom colorScheme, viewport and baseURL set:
@@ -62,109 +96,26 @@ public class ExampleTest : PageTest
         };
     }
 }
-
 ```
 
-### Customizing [Browser]/launch options
+</TabItem>
 
-[Browser]/launch options can be overridden either using a run settings file or by setting the run settings options directly via the CLI. See the following example:
-
-```xml
-<?xml version="1.0" encoding="utf-8"?>
-<RunSettings>
-  <Playwright>
-    <BrowserName>chromium</BrowserName>
-    <LaunchOptions>
-      <Headless>false</Headless>
-      <Channel>msedge</Channel>
-    </LaunchOptions>
-  </Playwright>
-</RunSettings>
-```
-
-```bash
-dotnet test -- Playwright.BrowserName=chromium Playwright.LaunchOptions.Headless=false Playwright.LaunchOptions.Channel=msedge
-```
-
-### Using Verbose API Logs
-
-When you have enabled the [verbose API log](./debug.mdx#verbose-api-logs), via the `DEBUG` environment variable, you will see the messages in the standard error stream. In MSTest, within Visual Studio, that will be the `Tests` pane of the `Output` window. It will also be displayed in the `Test Log` for each test.
-
-### Using the .runsettings file
-
-When running tests from Visual Studio, you can take advantage of the `.runsettings` file. The following shows a reference of the supported values.
-
-For example, to specify the number of workers, you can use `MSTest.Parallelize.Workers`. You can also enable `DEBUG` logs using `RunConfiguration.EnvironmentVariables`.
-
-```xml
-<RunSettings>
-  <!-- MSTest adapter -->  
-  <MSTest>
-    <Parallelize>
-      <Workers>4</Workers>
-      <Scope>ClassLevel</Scope>
-    </Parallelize>
-  </MSTest>
-  <!-- General run configuration -->
-  <RunConfiguration>
-    <EnvironmentVariables>
-      <!-- For debugging selectors, it's recommend to set the following environment variable -->
-      <DEBUG>pw:api</DEBUG>
-    </EnvironmentVariables>
-  </RunConfiguration>
-  <!-- Playwright -->  
-  <Playwright>
-    <BrowserName>chromium</BrowserName>
-    <ExpectTimeout>5000</ExpectTimeout>
-    <LaunchOptions>
-      <Headless>false</Headless>
-      <Channel>msedge</Channel>
-    </LaunchOptions>
-  </Playwright>
-</RunSettings>
-```
-
-### Base MSTest classes for Playwright
-
-There are a few base classes available to you in `Microsoft.Playwright.MSTest` namespace:
-
-|Test          |Description|
-|--------------|-----------|
-|PageTest      |Each test gets a fresh copy of a web [Page] created in its own unique [BrowserContext]. Extending this class is the simplest way of writing a fully-functional Playwright test.<br></br><br></br>Note: You can override the `ContextOptions` method in each test file to control context options, the ones typically passed into the [Browser.NewContextAsync()](/api/class-browser.mdx#browser-new-context) method. That way you can specify all kinds of emulation options for your test file individually.|
-|ContextTest   |Each test will get a fresh copy of a [BrowserContext]. You can create as many pages in this context as you'd like. Using this test is the easiest way to test multi-page scenarios where you need more than one tab.<br></br><br></br>Note: You can override the `ContextOptions` method in each test file to control context options, the ones typically passed into the [Browser.NewContextAsync()](/api/class-browser.mdx#browser-new-context) method. That way you can specify all kinds of emulation options for your test file individually.|
-|BrowserTest   |Each test will get a browser and can create as many contexts as it likes. Each test is responsible for cleaning up all the contexts it created.|
-|PlaywrightTest|This gives each test a Playwright object so that the test could start and stop as many browsers as it likes.|
-
-## NUnit
-
-Playwright provides base classes to write tests with NUnit via the [`Microsoft.Playwright.NUnit`](https://www.nuget.org/packages/Microsoft.Playwright.NUnit) package.
-
-Check out the [installation guide](./intro.mdx) to get started.
-
-### Running NUnit tests in Parallel
-
-By default NUnit will run all test files in parallel, while running tests inside each file sequentially (`ParallelScope.Self`). It will create as many processes as there are cores on the host system. You can adjust this behavior using the NUnit.NumberOfTestWorkers parameter. Only `ParallelScope.Self` is supported.
-
-For CPU-bound tests, we recommend using as many workers as there are cores on your system, divided by 2. For IO-bound tests you can use as many workers as you have cores.
-
-```bash
-dotnet test -- NUnit.NumberOfTestWorkers=5
-```
-
-### Customizing [BrowserContext] options
+<TabItem value="mstest">
 
 To customize context options, you can override the `ContextOptions` method of your test class derived from `Microsoft.Playwright.MSTest.PageTest` or `Microsoft.Playwright.MSTest.ContextTest`. See the following example:
 
 ```csharp
-using Microsoft.Playwright.NUnit;
+using System.Threading.Tasks;
+using Microsoft.Playwright;
+using Microsoft.Playwright.MSTest;
+using Microsoft.VisualStudio.TestTools.UnitTesting;
 
 namespace PlaywrightTests;
 
-[Parallelizable(ParallelScope.Self)]
-[TestFixture]
-public class MyTest : PageTest
+[TestClass]
+public class ExampleTest : PageTest
 {
-    [Test]
+    [TestMethod]
     public async Task TestWithCustomContextOptions()
     {
         // The following Page (and BrowserContext) instance has the custom colorScheme, viewport and baseURL set:
@@ -185,9 +136,14 @@ public class MyTest : PageTest
         };
     }
 }
+
 ```
 
-### Customizing [Browser]/launch options
+</TabItem>
+
+</Tabs>
+
+## Customizing [Browser]/launch options
 
 [Browser]/launch options can be overridden either using a run settings file or by setting the run settings options directly via the CLI. See the following example:
 
@@ -208,15 +164,19 @@ public class MyTest : PageTest
 dotnet test -- Playwright.BrowserName=chromium Playwright.LaunchOptions.Headless=false Playwright.LaunchOptions.Channel=msedge
 ```
 
-### Using Verbose API Logs
+## Using Verbose API Logs
 
-When you have enabled the [verbose API log](./debug.mdx#verbose-api-logs), via the `DEBUG` environment variable, you will see the messages in the standard error stream. In NUnit, within Visual Studio, that will be the `Tests` pane of the `Output` window. It will also be displayed in the `Test Log` for each test.
+When you have enabled the [verbose API log](./debug.mdx#verbose-api-logs), via the `DEBUG` environment variable, you will see the messages in the standard error stream. Within Visual Studio, that will be the `Tests` pane of the `Output` window. It will also be displayed in the `Test Log` for each test.
 
-### Using the .runsettings file
+## Using the .runsettings file
 
 When running tests from Visual Studio, you can take advantage of the `.runsettings` file. The following shows a reference of the supported values.
 
-For example, to specify the amount of workers you can use `NUnit.NumberOfTestWorkers` or to enable `DEBUG` logs `RunConfiguration.EnvironmentVariables`.
+<Tabs groupId="test-runners" defaultValue="mstest" values={[ {label: 'MSTest', value: 'mstest'}, {label: 'NUnit', value: 'nunit'}, ] }>
+
+<TabItem value="nunit">
+
+For example, to specify the number of workers you can use `NUnit.NumberOfTestWorkers` or to enable `DEBUG` logs `RunConfiguration.EnvironmentVariables`.
 
 ```xml
 <?xml version="1.0" encoding="utf-8"?>
@@ -244,10 +204,62 @@ For example, to specify the amount of workers you can use `NUnit.NumberOfTestWor
 </RunSettings>
 ```
 
-### Base NUnit classes for Playwright
+</TabItem>
+
+<TabItem value="mstest">
+
+For example, to specify the number of workers, you can use `MSTest.Parallelize.Workers`. You can also enable `DEBUG` logs using `RunConfiguration.EnvironmentVariables`.
+
+```xml
+<RunSettings>
+  <!-- MSTest adapter -->  
+  <MSTest>
+    <Parallelize>
+      <Workers>4</Workers>
+      <Scope>ClassLevel</Scope>
+    </Parallelize>
+  </MSTest>
+  <!-- General run configuration -->
+  <RunConfiguration>
+    <EnvironmentVariables>
+      <!-- For debugging selectors, it's recommend to set the following environment variable -->
+      <DEBUG>pw:api</DEBUG>
+    </EnvironmentVariables>
+  </RunConfiguration>
+  <!-- Playwright -->  
+  <Playwright>
+    <BrowserName>chromium</BrowserName>
+    <ExpectTimeout>5000</ExpectTimeout>
+    <LaunchOptions>
+      <Headless>false</Headless>
+      <Channel>msedge</Channel>
+    </LaunchOptions>
+  </Playwright>
+</RunSettings>
+```
+
+</TabItem>
+
+</Tabs>
+
+## Base classes for Playwright
+
+<Tabs groupId="test-runners" defaultValue="mstest" values={[ {label: 'MSTest', value: 'mstest'}, {label: 'NUnit', value: 'nunit'}, ] }>
+
+<TabItem value="nunit">
 
 There are a few base classes available to you in `Microsoft.Playwright.NUnit` namespace:
 
+</TabItem>
+
+<TabItem value="mstest">
+
+There are a few base classes available to you in `Microsoft.Playwright.MSTest` namespace:
+
+</TabItem>
+
+</Tabs>
+
 |Test          |Description|
 |--------------|-----------|
 |PageTest      |Each test gets a fresh copy of a web [Page] created in its own unique [BrowserContext]. Extending this class is the simplest way of writing a fully-functional Playwright test.<br></br><br></br>Note: You can override the `ContextOptions` method in each test file to control context options, the ones typically passed into the [Browser.NewContextAsync()](/api/class-browser.mdx#browser-new-context) method. That way you can specify all kinds of emulation options for your test file individually.|

diff --git a/java/docs/actionability.mdx b/java/docs/actionability.mdx
@@ -93,11 +93,20 @@ Element is considered stable when it has maintained the same bounding box for at
 
 ## Enabled
 
-Element is considered enabled unless it is a `<button>`, `<select>`, `<input>` or `<textarea>` with a `disabled` property.
+Element is considered enabled when it is **not disabled**.
+
+Element is **disabled** when:
+- it is a `<button>`, `<select>`, `<input>`, `<textarea>`, `<option>` or `<optgroup>` with a `[disabled]` attribute;
+- it is a `<button>`, `<select>`, `<input>`, `<textarea>`, `<option>` or `<optgroup>` that is a part of a `<fieldset>` with a `[disabled]` attribute;
+- it is a descendant of an element with `[aria-disabled=true]` attribute.
 
 ## Editable
 
-Element is considered editable when it is [enabled] and does not have `readonly` property set.
+Element is considered editable when it is [enabled] and is **not readonly**.
+
+Element is **readonly** when:
+- it is a `<select>`, `<input>` or `<textarea>` with a `[readonly]` attribute;
+- it has an `[aria-readonly=true]` attribute and an aria role that [supports it](https://w3c.github.io/aria/#aria-readonly).
 
 ## Receives Events
 

diff --git a/java/docs/api/class-locator.mdx b/java/docs/api/class-locator.mdx
@@ -1493,7 +1493,7 @@ boolean disabled = page.getByRole(AriaRole.BUTTON).isDisabled();
 
 <font size="2" style={{position: "relative", top: "-20px"}}>Added in: v1.14</font><x-search>locator.isEditable</x-search>
 
-Returns whether the element is [editable](../actionability.mdx#editable).
+Returns whether the element is [editable](../actionability.mdx#editable). If the target element is not an `<input>`, `<textarea>`, `<select>`, `[contenteditable]` and does not have a role allowing `[aria-readonly]`, this method throws an error.
 
 :::warning[Asserting editable state]