blink: document skipped bidi tests and fix typos
Change-Id: I80e808f1d9b05e351fe93c4da2dd93ddffcc426e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4684134
Auto-Submit: Thiago Perrotta <[email protected]>
Reviewed-by: Vladimir Nechaev <[email protected]>
Commit-Queue: Thiago Perrotta <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1170626}
diff --git a/docs/testing/web_tests.md b/docs/testing/web_tests.md
index 6316f54..1d7d745 100644
--- a/docs/testing/web_tests.md
+++ b/docs/testing/web_tests.md
@@ -60,7 +60,7 @@
To specify which build directory to use (e.g. out/Default, etc.)
you should pass the `-t` or `--target` parameter. If no directory is specified,
-`out/Release` will be used. To use the build in `out/Default`, use:
+`out/Release` will be used. To use the built-in `out/Default`, use:
```bash
third_party/blink/tools/run_web_tests.py -t Default
@@ -249,7 +249,7 @@
*** note
[BUILD.gn](../../BUILD.gn) assumes flag-specific builders always runs on linux bots, so
flag-specific test expectations and baselines are only downloaded to linux bots.
-If you need run flag-specific builders on other platforms, please update
+If you need run flag-specific builderst-n other platforms, please update
BUILD.gn to download flag-specific related data to that platform.
***
@@ -295,7 +295,7 @@
`web_tests/TestExpectations`, and their own baselines. The test harness will
use the non-virtual expectations and baselines as a fallback. If a virtual
test has its own expectations, they will override all non-virtual
-expectations. otherwise the non-virtual expectations will be used. However,
+expectations. Otherwise the non-virtual expectations will be used. However,
`[ Slow ]` in either virtual or non-virtual expectations is always merged
into the used expectations. If a virtual test is expected to pass while the
non-virtual test is expected to fail, you need to add an explicit `[ Pass ]`
@@ -352,7 +352,7 @@
For flags whose implementation is still in progress, flag-specific expectations
and virtual test suites represent two alternative strategies for testing both
-the enabled code path and not-enabled code path. They are preferred to only
+the enabled code path and non-enabled code path. They are preferred to only
setting a [runtime enabled feature](../../third_party/blink/renderer/platform/RuntimeEnabledFeatures.md)
to `status: "test"` if the feature has substantially different code path from
production because the latter would cause loss of test coverage of the production
