docs: purge devtools

Author: KuznetsovRoman

docs/guides/how-to-use-cdp.mdx

@@ -24,16 +24,24 @@ For a comparison of the _WebDriver_ and _CDP_ protocols, see the "WebDriver vs C
 
 ## Local Usage {#local_usage}
 
-To work with the browser via CDP locally, add the `automationProtocol: 'devtools'` option to the browser settings in the Testplane config:
+<Admonition type="danger" title="Removed in Testplane 9">
+    Starting from **Testplane 9**, the value `"devtools"` for the `automationProtocol` option (as well as the `--devtools` CLI flag) has been **removed**. It caused a number of hard-to-reproduce errors that never occurred with `automationProtocol: "webdriver"`, and the underlying [WebdriverIO](https://webdriver.io) — on which Testplane is based — has also dropped its `devtools` automation protocol. The only supported value is now `"webdriver"` (which is also the default).
+
+    Note that this does **not** deprecate the Chrome DevTools Protocol itself: you can still use CDP directly (see the [Remote Usage](#remote_usage) section below and the rest of this page). Only the `devtools` automation protocol provided by WebdriverIO has been removed.
+
+</Admonition>
+
+To run your tests in a locally installed browser, use `gridUrl: "local"` (or the `--local` CLI flag) — Testplane will automatically download the required browsers and drivers and launch them via WebDriver:
 
 ```javascript
 // .testplane.conf.js
 
 module.exports = {
     browsers: {
         chrome: {
-            automationProtocol: "devtools",
+            gridUrl: "local",
             desiredCapabilities: {
+                browserName: "chrome",
                 // ...
             },
         },
@@ -47,17 +55,15 @@ module.exports = {
 
 After this, all subsequent runs will be performed in your locally installed Chrome.
 
-But if you need to run a browser with CDP support just once, it's more convenient to override this option using an environment variable:
+If you need to launch tests on a local browser just once, you can pass the `--local` CLI option instead:
 
 ```bash
-testplane_browsers_chrome_automation_protocol=devtools npx testplane ...
+npx testplane ... --local
 ```
 
-Or set it as a CLI option:
+See the [Running on Local Browsers](/blog/local-browsers-intro) blog post for a step-by-step guide.
 
-```bash
-npx testplane ... --browsers-chrome-automation-protocol=devtools
-```
+Once the browser is started locally via WebDriver, you can still call [CDP commands][how-to-intercept-requests-and-responses] inside the test as described in the [Remote Usage](#remote_usage) section.
 
 ## Remote Usage {#remote_usage}
 

docs/quickstart/running-tests.mdx

@@ -2,8 +2,6 @@
 sidebar_position: 3
 ---
 
-import Admonition from "@theme/Admonition";
-
 # Running and Debugging
 
 ## Running tests
@@ -152,22 +150,20 @@ npx testplane gui
 
 In the GUI you will see test execution in real time, screenshots, and errors. You can restart individual tests and observe their execution.
 
-### Local browser with DevTools
+### Visible local browser
 
-For debugging, you can open a visible browser window with DevTools:
+For debugging, you can open a visible browser window:
 
 ```bash
-npx testplane --local --devtools --headless false --grep "Test name"
+npx testplane --local --headless false --grep "Test name"
 ```
 
 What will happen:
 
-1.  A visible browser window will open
-2.  Chrome DevTools will automatically open
+1.  Testplane will download the browser and driver if needed (`--local` is the same as `gridUrl: "local"` in the config)
+2.  A visible browser window will open
 3.  You can observe the test execution
 
-<Admonition type="warning">Firefox browser does not support DevTools.</Admonition>
-
 ### REPL mode
 
 REPL (Read-Eval-Print Loop) is an interactive console for executing browser commands during a test. There are several ways to enter REPL:

docs/reference/cli.mdx

@@ -30,7 +30,6 @@ Main command to run tests.
     --repl [type]                    run one test, call `browser.switchToRepl` in test code to open repl interface (default: false)
     --repl-before-test [type]        open repl interface before test run (default: false)
     --repl-on-fail [type]            open repl interface on test fail only (default: false)
-    --devtools                       switches the browser to the devtools mode with using CDP protocol
     --local                          use automatically downloaded browsers and drivers, provided by Testplane
     --keep-browser                   do not close browser session after test completion
     --keep-browser-on-fail           do not close browser session when test fails
@@ -256,11 +255,14 @@ Example of console output with connection information to the browser:
 
 #### Devtools {#testplane-devtools}
 
-Runs Testplane tests using [devtools automation protocol][webdriver-vs-cdp].
+<Admonition type="danger" title="Removed in Testplane 9">
+    The `--devtools` CLI option (and the corresponding `automationProtocol: "devtools"` value) was **removed** in Testplane 9. The `devtools` automation protocol — provided by WebdriverIO — caused a number of hard-to-reproduce issues that never occurred under WebDriver, and WebdriverIO has also dropped its `devtools` automation protocol. The only supported value of `automationProtocol` is now `"webdriver"` (the default).
 
-```bash
-testplane --devtools
-```
+    To run tests in a locally installed browser, use `gridUrl: "local"` in the [config](../config/browsers#automation_protocol) or the `--local` CLI option. See [Running on Local Browsers](/blog/local-browsers-intro) for details.
+
+    Note: this does not deprecate the Chrome DevTools Protocol itself — you can still use it directly from tests, see the [How to Use Chrome DevTools Protocol][how-to-use-cdp] guide.
+
+</Admonition>
 
 #### Help {#testplane-help}
 
@@ -771,3 +773,4 @@ TESTPLANE_SETS=desktop,touch testplane
 [add-tag]: ../../commands/browser/addTag
 [switch-to-repl]: ../../commands/browser/switchToRepl
 [webdriver-vs-cdp]: ../webdriver-vs-cdp
+[how-to-use-cdp]: ../../guides/how-to-use-cdp

docs/reference/config/_partials/examples/_config-example.mdx

@@ -10,10 +10,10 @@ export default {
 
     browsers: {
         chrome: {
+            gridUrl: "local",
+            headless: true,
             desiredCapabilities: {
                 browserName: "chrome",
-                automationProtocol: "devtools",
-                headless: true,
             },
         },
     },

docs/reference/config/browsers.mdx

@@ -165,6 +165,15 @@ Default value: `null`. It means that Testplane will try to determine the websock
 
 Protocol for communication with the browser. Available values: `webdriver` and `devtools`. See also [WebDriver vs CDP](../../webdriver-vs-cdp). Default: `webdriver`.
 
+<Admonition type="danger" title="Removed in Testplane 9">
+    Starting from **Testplane 9**, the value `"devtools"` has been **removed**. It caused a number of hard-to-reproduce errors that never occurred under `"webdriver"`, and the underlying [WebdriverIO](https://webdriver.io) has also dropped its `devtools` automation protocol. The only supported value is now `"webdriver"`.
+
+    To launch tests in a locally installed browser, use [`gridUrl: "local"`](#grid_url) instead — Testplane will automatically download the required browser and driver and start it via WebDriver. See the [Running on Local Browsers](/blog/local-browsers-intro) blog post for a step-by-step guide.
+
+    This change does **not** affect the Chrome DevTools Protocol itself — you can still use CDP from your tests, see the [How to Use Chrome DevTools Protocol][how-to-use-cdp] guide.
+
+</Admonition>
+
 ### sessionEnvFlags {#session_env_flags}
 
 Environment flags set the protocols that will be used in the created browser session. By default, environment flags are automatically set according to the specified `desiredCapabilities`. However, in rare cases, they may have incorrect values and can be explicitly set using this option.

i18n/ru/docusaurus-plugin-content-docs/current/guides/how-to-use-cdp.mdx

@@ -22,16 +22,24 @@ import Admonition from "@theme/Admonition";
 
 ## Локальное использование {#local_usage}
 
-Для работы с браузером по CDP локально — добавьте опцию `automationProtocol: 'devtools'` к настройкам браузера в конфиге testplane:
+<Admonition type="danger" title="Удалено в Testplane 9">
+    Начиная с **Testplane 9** значение `"devtools"` у опции `automationProtocol` (а также CLI-флаг `--devtools`) **удалены**. Этот режим вызывал ряд трудновоспроизводимых ошибок, которых не было при `automationProtocol: "webdriver"`, и в [WebdriverIO](https://webdriver.io), на котором основан Testplane, протокол автоматизации `devtools` также был удалён. Единственное поддерживаемое значение теперь — `"webdriver"` (оно же и значение по умолчанию).
+
+    Это **не** означает отказ от самого Chrome DevTools Protocol: вы по-прежнему можете напрямую использовать CDP (см. секцию [Удалённое использование](#remote_usage) ниже и остальную часть этой страницы). Удалён только режим автоматизации `devtools`, который ранее предоставлял WebdriverIO.
+
+</Admonition>
+
+Чтобы запустить тесты в локально установленном браузере, укажите `gridUrl: "local"` (или передайте CLI-флаг `--local`) — Testplane сам скачает необходимые браузеры и драйверы и запустит их по протоколу WebDriver:
 
 ```javascript
 // .testplane.conf.js
 
 module.exports = {
     browsers: {
         chrome: {
-            automationProtocol: "devtools",
+            gridUrl: "local",
             desiredCapabilities: {
+                browserName: "chrome",
                 // ...
             },
         },
@@ -45,12 +53,16 @@ module.exports = {
 
 После этого все последующие запуски будут выполняться в вашем локально установленном Хроме.
 
-Но если вам нужно запустить браузер с поддержкой CDP один раз, то удобнее использовать специальную CLI-опцию:
+Если вам нужно запустить тесты на локальном браузере однократно, передайте CLI-опцию `--local`:
 
 ```bash
-npx testplane ... --devtools
+npx testplane ... --local
 ```
 
+Подробная пошаговая инструкция есть в блог-посте [Запуск на локальных браузерах](/blog/local-browsers-intro).
+
+После того как браузер поднят локально по WebDriver, в тесте по-прежнему можно вызывать [CDP-команды][how-to-intercept-requests-and-responses] так же, как описано в секции [Удалённое использование](#remote_usage).
+
 ## Удаленное использование {#remote_usage}
 
 При использовании CDP на удаленной машине (например, в гриде) testplane сначала поднимет браузер с использованием WebDriver-протокола и только потом, по запросу пользователя (т. е. при вызове CDP-команды), перейдет на подключение по CDP. Таким образом, с удаленным браузером в одном тестовом сценарии мы будем общаться сразу по двум протоколам.

i18n/ru/docusaurus-plugin-content-docs/current/quickstart/running-tests.mdx

@@ -2,8 +2,6 @@
 sidebar_position: 3
 ---
 
-import Admonition from "@theme/Admonition";
-
 # Запуск и отладка
 
 ## Запуск тестов
@@ -152,22 +150,20 @@ npx testplane gui
 
 В GUI вы увидите выполнение тестов в реальном времени, скриншоты и ошибки. Можно перезапускать отдельные тесты и наблюдать за их выполнением.
 
-### Локальный браузер с DevTools
+### Видимый локальный браузер
 
-Для отладки можно открыть видимое окно браузера с DevTools:
+Для отладки можно открыть видимое окно браузера:
 
 ```bash
-npx testplane --local --devtools --headless false --grep "Название теста"
+npx testplane --local --headless false --grep "Название теста"
 ```
 
 Что произойдет:
 
-1.  Откроется видимое окно браузера
-2.  Автоматически откроются Chrome DevTools
+1.  Testplane при необходимости скачает браузер и драйвер (`--local` эквивалентен `gridUrl: "local"` в конфиге)
+2.  Откроется видимое окно браузера
 3.  Вы сможете наблюдать за выполнением теста
 
-<Admonition type="warning">В браузере Firefox нет поддержки DevTools.</Admonition>
-
 ### REPL-режим
 
 REPL (Read-Eval-Print Loop) — интерактивная консоль для выполнения команд браузера во время теста. Есть несколько способов войти в REPL:

i18n/ru/docusaurus-plugin-content-docs/current/reference/cli.mdx

@@ -30,7 +30,6 @@ import Version from "../_partials/specs/version.mdx";
     --repl [type]                    run one test, call `browser.switchToRepl` in test code to open repl interface (default: false)
     --repl-before-test [type]        open repl interface before test run (default: false)
     --repl-on-fail [type]            open repl interface on test fail only (default: false)
-    --devtools                       switches the browser to the devtools mode with using CDP protocol
     --local                          use automatically downloaded browsers and drivers, provided by Testplane
     --keep-browser                   do not close browser session after test completion
     --keep-browser-on-fail           do not close browser session when test fails
@@ -257,11 +256,14 @@ testplane --repl --grep 'my test name' --browser chrome
 
 #### Devtools {#testplane-devtools}
 
-Запускает тесты Testplane с использованием [протокола автоматизации devtools][webdriver-vs-cdp].
+<Admonition type="danger" title="Удалено в Testplane 9">
+    CLI-опция `--devtools` (и соответствующее ей значение `automationProtocol: "devtools"`) **удалена** в Testplane 9. Протокол автоматизации `devtools`, который предоставлял WebdriverIO, вызывал ряд трудновоспроизводимых ошибок, которых не было при использовании WebDriver, и в самом WebdriverIO протокол автоматизации `devtools` тоже был удалён. Единственным поддерживаемым значением `automationProtocol` теперь является `"webdriver"` (оно же и значение по умолчанию).
 
-```bash
-testplane --devtools
-```
+    Чтобы запустить тесты в локально установленном браузере, используйте `gridUrl: "local"` в [конфиге](../config/browsers#automation_protocol) или CLI-опцию `--local`. Подробности — в блог-посте [Запуск на локальных браузерах](/blog/local-browsers-intro).
+
+    Обратите внимание: это не означает отказ от самого Chrome DevTools Protocol — вы по-прежнему можете напрямую использовать CDP в тестах, см. рецепт [Как использовать Chrome DevTools Protocol в testplane][how-to-use-cdp].
+
+</Admonition>
 
 #### Help {#testplane-help}
 
@@ -772,3 +774,4 @@ TESTPLANE_SETS=desktop,touch testplane
 [add-tag]: ../../commands/browser/addTag
 [switch-to-repl]: ../../commands/browser/switchToRepl
 [webdriver-vs-cdp]: ../webdriver-vs-cdp
+[how-to-use-cdp]: ../../guides/how-to-use-cdp

i18n/ru/docusaurus-plugin-content-docs/current/reference/config/_partials/examples/_config-example.mdx

@@ -10,10 +10,10 @@ export default {
 
     browsers: {
         chrome: {
+            gridUrl: "local",
+            headless: "new",
             desiredCapabilities: {
                 browserName: "chrome",
-                automationProtocol: "devtools",
-                headless: true,
             },
         },
     },

i18n/ru/docusaurus-plugin-content-docs/current/reference/config/browsers.mdx

@@ -163,6 +163,15 @@ URL грида (адрес, на котором слушает ChromeDriver/Sele
 
 Протокол общения с браузером. Доступные значения: `webdriver` и `devtools`. См. также [WebDriver vs CDP](../../webdriver-vs-cdp). По умолчанию: `webdriver`.
 
+<Admonition type="danger" title="Удалено в Testplane 9">
+    Начиная с **Testplane 9** значение `"devtools"` **удалено**. Этот режим вызывал ряд трудновоспроизводимых ошибок, которых не было при `"webdriver"`, и в [WebdriverIO](https://webdriver.io), на котором основан Testplane, протокол автоматизации `devtools` также был удалён. Единственное поддерживаемое значение теперь — `"webdriver"`.
+
+    Чтобы запустить тесты в локально установленном браузере, используйте [`gridUrl: "local"`](#grid_url) — Testplane сам скачает нужный браузер и драйвер и запустит его по протоколу WebDriver. Пошаговая инструкция есть в блог-посте [Запуск на локальных браузерах](/blog/local-browsers-intro).
+
+    Это изменение **не** касается самого Chrome DevTools Protocol — вы по-прежнему можете использовать CDP в тестах, см. рецепт [Как использовать Chrome DevTools Protocol в testplane][how-to-use-cdp].
+
+</Admonition>
+
 ### sessionEnvFlags {#session_env_flags}
 
 Флаги окружения задают протоколы, которые будут использоваться в созданной сессии браузера. По умолчанию флаги окружения автоматически устанавливаются в соответствии с заданными `desiredCapabilities`. Однако в редких случаях они могут принимать некорректные значения и тогда с помощью этой опции их можно будет задать явно.