Run a spellchecker on src/docs/
I'd also like to use this CL as a test for crbug.com/1257744 Change-Id: Ie958c515680a2a130c257c23f826d5a30a3963ac Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3229977 Commit-Queue: Quinten Yearsley <qyearsley@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@google.com> Cr-Commit-Position: refs/heads/main@{#933514}
This commit is contained in:

committed by
Chromium LUCI CQ

parent
cc1025cd9f
commit
317532d47d
docs
README.md
accessibility
design
disassemble_code.mddocumentation_best_practices.mdgpu
infra
initialize_blink_features.mdinstallation_at_vmware.mdios
memory
native_relocations.mdproxy_auto_config.mdspeed
sublime_ide.mdsync
updater
vscode.md@ -180,7 +180,7 @@ used when committed.
|
||||
* [Using Crashpad with `content_shell`](testing/using_crashpad_with_content_shell.md) -
|
||||
Capture stack traces on layout test crashes without an attached debugger
|
||||
* [Test Descriptions](testing/test_descriptions.md) - Unit test targets that can be
|
||||
built, with associated desciptions.
|
||||
built, with associated descriptions.
|
||||
* [Fuzz Testing](../testing/libfuzzer/README.md) - Fuzz testing in Chromium.
|
||||
* [IPC Fuzzer](testing/ipc_fuzzer.md) - Fuzz testing of Chromium IPC interfaces.
|
||||
* [Running Chrome tests with AddressSanitizer (asan) and LeakSanitizer (lsan)](testing/linux_running_asan_tests.md) -
|
||||
@ -203,7 +203,7 @@ used when committed.
|
||||
* [Linux Proxy Config](linux/proxy_config.md) - Network proxy sources on Linux
|
||||
* [Debugging SSL on Linux](linux/debugging_ssl.md) - Tips on debugging SSL
|
||||
code in Linux
|
||||
* [Linux Cert Managment](linux/cert_management.md) - Managing X.509
|
||||
* [Linux Cert Management](linux/cert_management.md) - Managing X.509
|
||||
Certificates in Linux
|
||||
* [Tips for Debugging on Linux](linux/debugging.md)
|
||||
* [Linux GTK Theme Integration](linux/gtk_theme_integration.md) - Having
|
||||
@ -341,7 +341,7 @@ used when committed.
|
||||
* [BRLTTY in Chrome OS](accessibility/brltty.md) - Chrome OS integration with
|
||||
BRLTTY to support refreshable braille displays
|
||||
* [PATTS on Chrome OS](accessibility/patts.md) - Notes on the PATTS speech
|
||||
sythesis engine used on Chrome OS
|
||||
synthesis engine used on Chrome OS
|
||||
* [VoiceOver](ios/voiceover.md) - Using Apple's VoiceOver feature with
|
||||
Chromium on iOS.
|
||||
|
||||
|
@ -222,7 +222,7 @@ libbrlapi could require additional so versions be added to our loader.
|
||||
|
||||
2. modify the way in which brltty gets run.
|
||||
|
||||
In particular, look at the invokation of the minijail in
|
||||
In particular, look at the invocation of the minijail in
|
||||
|
||||
third_party/chromiumos-overlay/app-accessibility/brltty/files/brltty
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
Chrome OS comes with a port of the open-source eSpeak-NG speech synthesis
|
||||
engine. eSpeak-NG is lower quality than Google's "PATTS" speech engine,
|
||||
but it's faster, uses less resouces, and supports more languages.
|
||||
but it's faster, uses less resources, and supports more languages.
|
||||
|
||||
[Read more about Text-to-Speech in Chrome](tts.md).
|
||||
|
||||
|
@ -31,7 +31,7 @@ For example, the staticText node here is offscreen:
|
||||
|
||||
As background, [MSDN](https://msdn.microsoft.com/en-us/library/dd373609(VS.85).aspx)
|
||||
defines Offscreen as an object is not rendered, but not because it was
|
||||
programatically hidden:
|
||||
programmatically hidden:
|
||||
|
||||
>The object is clipped or has scrolled out of view, but it is not
|
||||
programmatically hidden. If the user makes the viewport larger, more of the
|
||||
@ -51,7 +51,7 @@ overflow:hidden, overflow:scroll, or it is a rootWebArea), offscreen is set to
|
||||
true.
|
||||
|
||||
## Invisible
|
||||
A node is marked Invisible in Chrome if it is hidden programatically. In some
|
||||
A node is marked Invisible in Chrome if it is hidden programmatically. In some
|
||||
cases, invisible nodes are simply excluded from the accessibility tree. Chrome
|
||||
defines invisible as:
|
||||
|
||||
|
@ -354,7 +354,7 @@ queries in the accessibility tree.
|
||||
To compactly store the bounding box of every character on the page, we
|
||||
split the text into *inline text boxes*, sometimes called *text runs*.
|
||||
For example, in a typical paragraph, each line of text would be its own
|
||||
inline text box. In general, an inline text box or text run contians a
|
||||
inline text box. In general, an inline text box or text run contains a
|
||||
sequence of text characters that are all oriented in the same direction,
|
||||
in a line, with the same font, size, and style.
|
||||
|
||||
|
@ -328,7 +328,7 @@ or node type directly.
|
||||
#### background.js
|
||||
|
||||
This file is the first one run. Its primary job is to create an instance of
|
||||
SwitchAccess, although it als overifies that there is not more than one instance
|
||||
SwitchAccess, although it also overifies that there is not more than one instance
|
||||
of Switch Access running simultaneously (this would normally happen on the sign
|
||||
in page).
|
||||
|
||||
|
@ -39,7 +39,7 @@ native GL fence, usable for cross-process synchronization.
|
||||
|
||||
## Use case overview
|
||||
|
||||
The core scenario is synchronizing read and write access to a shared resorce,
|
||||
The core scenario is synchronizing read and write access to a shared resource,
|
||||
for example drawing an image into an offscreen texture and compositing the
|
||||
result into a final image. The drawing operations need to be completed before
|
||||
reading to ensure correct output. A typical effect of wrong synchronization is
|
||||
|
@ -63,7 +63,7 @@ ninja -C out/RelNgSym
|
||||
```
|
||||
|
||||
You probably will want to add some more command line options to this,
|
||||
depending on your usual build paralellism.
|
||||
depending on your usual build parallelism.
|
||||
|
||||
## Getting the right objdump
|
||||
|
||||
|
@ -93,7 +93,7 @@ to detailed prose:
|
||||
* Who maintains this directory and where I can learn more?
|
||||
|
||||
4. **Design docs, PRDs**: A good design doc or PRD discusses the proposed
|
||||
implementation at length for the purpose of collecting feeback on that
|
||||
implementation at length for the purpose of collecting feedback on that
|
||||
design. However, once the code is implemented, design docs should serve as
|
||||
archives of these decisions, not as half-correct docs (they are often
|
||||
misused). See
|
||||
|
@ -551,7 +551,7 @@ itself will contain links. In either case, these links will direct to Gold
|
||||
pages showing the image produced by the image and the approved image that most
|
||||
closely matches it.
|
||||
|
||||
Note that for the tests which programatically check colors in certain regions of
|
||||
Note that for the tests which programmatically check colors in certain regions of
|
||||
the image (tests with `expected_colors` fields in [pixel_test_pages]), there
|
||||
likely won't be a closest approved image since those tests only upload data to
|
||||
Gold in the event of a failure.
|
||||
|
@ -146,7 +146,7 @@ There are several requirements for a builder to be added to the Commit Queue.
|
||||
* It should be possible for any committer to replicate any testing run; i.e.
|
||||
tests and their data must be in the public repository.
|
||||
* Median cycle time needs to be under 40 minutes for trybots. 90th percentile
|
||||
should be around an hour (preferrably shorter).
|
||||
should be around an hour (preferably shorter).
|
||||
* Configurations need to catch enough failures to be worth adding to the CQ.
|
||||
Running builds on every CL requires a significant amount of compute resources.
|
||||
If a configuration only fails once every couple of weeks on the waterfalls,
|
||||
|
@ -55,7 +55,7 @@ default status):
|
||||
\[1]: `base::FeatureList::IsEnabled(features::kNewFeatureX)` is still
|
||||
false. These combinations are suitable for features there are fully implemented
|
||||
at blink side. Otherwise normally the blink feature should not have a status so
|
||||
that the Chromium feature can fully controll the feature.
|
||||
that the Chromium feature can fully control the feature.
|
||||
|
||||
\[2]: This combination is counter-intuitive and should be avoided.
|
||||
|
||||
|
@ -10,7 +10,7 @@
|
||||
1. Create a New Virtual Machine
|
||||
1. Do not selecting any OP-sys (other-other-etc)
|
||||
1. Delete your newly created hardisc (lets say you named it as Chrome)
|
||||
1. Move downloaded harddisc to the same folder as othere VMware files for this
|
||||
1. Move downloaded harddisc to the same folder as other VMware files for this
|
||||
Virtual Machine
|
||||
1. Rename your downloaded hardisc to newly created Virtual Machine original
|
||||
name (in my example it was Chrome)
|
||||
|
@ -237,7 +237,7 @@ installed that could sign the `ios_web_shell.app` bundle with the identity
|
||||
request such a mobile provisioning profile from Apple.
|
||||
|
||||
You can inspect the file passed via the `-e` flag to the `codesign.py` script
|
||||
to check which capabilites are required for the mobile provisioning profile
|
||||
to check which capabilities are required for the mobile provisioning profile
|
||||
(e.g. `src/build/config/ios/entitlements.plist` for the above build error,
|
||||
remember that the paths are relative to the build directory, not to the source
|
||||
directory).
|
||||
|
@ -40,7 +40,7 @@ To look a the delta between two dumps, control-click two different dark-purple M
|
||||
circles.
|
||||
|
||||
### Blindspots
|
||||
* Statistics are self-reported. If the MemoryDumpProvider implemenation does
|
||||
* Statistics are self-reported. If the MemoryDumpProvider implementation does
|
||||
not fully cover the resource usage of the subsystem, those resources will
|
||||
not be accounted.
|
||||
|
||||
@ -157,7 +157,7 @@ looking similar due to the nature of DOM node allocation.
|
||||
| ------- | ----- |
|
||||
| Out of process heap profiling start mode. | This option is somewhat misnamed. It tells OOPHP which processes to profile at startup. Other processes can selected manually later via chrome://memory-internals even if this is set to "disabled". |
|
||||
| Keep track of even the small allocations in memlog heap dumps. | By default, small allocations are not emitted in the heap dump to reduce dump size. Enabling this track _all_ allocations. |
|
||||
| The type of stack to record for memlog heap dumps | If possible, use Native stack frames as that provides the best information. When those are not availble either due to performance for build (eg, no frame-pointers on arm32 official) configurations, using trace events for a "pseudo stack" can give good information too. |
|
||||
| The type of stack to record for memlog heap dumps | If possible, use Native stack frames as that provides the best information. When those are not available either due to performance for build (eg, no frame-pointers on arm32 official) configurations, using trace events for a "pseudo stack" can give good information too. |
|
||||
| Heap profiling | Deprecated. Enables the in-process heap profiler. Functionality should be fully subsumed by preceeding options. |
|
||||
|
||||
#### Saving a heap dump
|
||||
@ -168,7 +168,7 @@ looking similar due to the nature of DOM node allocation.
|
||||
2. Symbolize trace using [`symbolize_trace.py`](../../third_party/catapult/tracing/bin/symbolize_trace). If the Chrome binary was built locally, pass the flag "--is-local-build".
|
||||
3. Analyze resuing heap dump using [`diff_heap_profiler.py`](#diff-heap-profiler), or [Heap Profile view in Chrome Tracing](#tracing-heap-profile)
|
||||
|
||||
On deskop, using chrome://memory-internals to take a heap dump is more reliable
|
||||
On desktop, using chrome://memory-internals to take a heap dump is more reliable
|
||||
as it directly saves the heapdump to a file instead of passing the serialized data
|
||||
through the chrome://tracing renderer process which can easily OOM. For Android,
|
||||
this native file saving was harder to implement and would still leave the
|
||||
@ -259,10 +259,10 @@ can notice kernel resources that are allocated (eg, GPU memory, or drive memory
|
||||
such as the Windows Paged and Non-paged pools) as side effects of user mode
|
||||
calls nor do they account for memory that does not go through new/malloc
|
||||
(manulaly callling `mmap()`, or `VirtualAlloc()`). Querying a full view of
|
||||
these allocaitons usually requires admin privileges, the semantics change
|
||||
these allocations usually requires admin privileges, the semantics change
|
||||
per platform, and the performance can vary from being "constant-ish" to
|
||||
being dependent on virtual space size (eg, probing allocation via
|
||||
VirtualQueryEx or parsing /proc/self/maps) or number of proccesses in the
|
||||
VirtualQueryEx or parsing /proc/self/maps) or number of processes in the
|
||||
system (NTQuerySystemInformation).
|
||||
|
||||
As an example of error in measurement, PartitionAlloc did not account for
|
||||
|
@ -30,7 +30,7 @@
|
||||
[cros]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1210982
|
||||
|
||||
### Windows Relocations (PE Format)
|
||||
* For PE files, relocaitons are stored in per-code-page
|
||||
* For PE files, relocations are stored in per-code-page
|
||||
[`.reloc` sections][win_relocs].
|
||||
* Each relocation is stored using 2 bytes. Each `.reloc` section has a small
|
||||
overhead as well.
|
||||
|
@ -1,7 +1,7 @@
|
||||
# Proxy Auto Config Using WPAD
|
||||
|
||||
Most systems support manually configuring a proxy for web access, but this is
|
||||
cumbersome and kind of techical, so Chrome also supports
|
||||
cumbersome and kind of technical, so Chrome also supports
|
||||
[WPAD](http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) for proxy
|
||||
configuration (enabled if "automatically detect proxy settings" is enabled on
|
||||
Windows).
|
||||
|
@ -151,7 +151,7 @@ to see if your intended user stories are already covered by existing ones.
|
||||
If there is a good reason for your stories to be added, please make one CL for
|
||||
each of the new stories so they can be landed (and reverted if needed)
|
||||
individually. On each CL, make sure that the perf trybots all pass before
|
||||
comitting.
|
||||
committing.
|
||||
|
||||
Once your patch makes it through the CQ, you’re done… unless your story starts
|
||||
failing on some random platform, in which case the perf bot sheriff will very
|
||||
|
@ -20,7 +20,7 @@ which controls the user interactions and duration of the test.
|
||||
The [`webrtc.py`](../../../../tools/perf/benchmarks/webrtc.py)
|
||||
benchmark specifies which metrics should be collected for the
|
||||
test pages, and extra options that we pass to the test to fake the real camera
|
||||
and skip assing permission to get access to the video and audio from the user.
|
||||
and skip assign permission to get access to the video and audio from the user.
|
||||
|
||||
|
||||
## Running the Tests
|
||||
|
@ -14,7 +14,7 @@ This document lists metrics used to track binary size.
|
||||
|
||||
### Alerting
|
||||
|
||||
* Alerts are sheriffed as part of the main perf sherif rotation.
|
||||
* Alerts are sheriffed as part of the main perf sheriff rotation.
|
||||
* Alerts generally fire for ~100kb jumps.
|
||||
|
||||
## Metrics for Android
|
||||
|
@ -35,7 +35,7 @@ https://crbug.com/889742 is has more details and many duped bugs.
|
||||
|
||||
### No-op refactors that prevent AFDO
|
||||
|
||||
It's also possible to make no-op changes to code, cauing the previous AFDO data
|
||||
It's also possible to make no-op changes to code, causing the previous AFDO data
|
||||
to be inapplicable (e.g. function name change). This can result in apparent
|
||||
regressions which recover spontaneously once new AFDO data is generated based on
|
||||
the new code. E.g. https://crbug.com/855544 was a specific case of this. One way
|
||||
|
@ -49,7 +49,7 @@ interact with a website.
|
||||
## Responsiveness
|
||||
|
||||
Responsiveness domain focuses on making sure all websites have smooth transitions
|
||||
by serving 60fps, and that the click to action time is not noticible.
|
||||
by serving 60fps, and that the click to action time is not noticeable.
|
||||
|
||||
* Performance-Responsiveness [Bug
|
||||
Queue](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=Performance%3DResponsiveness)
|
||||
|
@ -255,7 +255,7 @@ With [Chromium X-Refs](https://github.com/karlinjf/ChromiumXRefs/) you can
|
||||
perform [https://cs.chromium.org](https://cs.chromium.org) cross-reference
|
||||
searches in your editor. This gives you the call graph, overrides, references,
|
||||
declaration, and definition of most of the code. The results are as fresh as
|
||||
the search engine's index so uncomitted changes won't be reflected.
|
||||
the search engine's index so uncommitted changes won't be reflected.
|
||||
|
||||
More information on Chromium X-Ref's functionality (including keyboard and
|
||||
mouse shortcuts) can be found on the [Chromium X-Refs
|
||||
|
@ -32,7 +32,7 @@ immediately created to replace it.
|
||||
## Processor State Machines
|
||||
|
||||
The processor sits between the model bridge and the sync engine. It has
|
||||
knowledge of what state each is in based on the calls it has receieved and
|
||||
knowledge of what state each is in based on the calls it has received and
|
||||
performed. The states are not stored explicitly, but are implicit based on
|
||||
state stored in the processor. Here are the states of each, with notes on their
|
||||
transitions and how to determine them.
|
||||
|
@ -150,7 +150,7 @@ Additions to the protocol that specify backward-compatible default values (often
|
||||
with a semantic meaning of "unknown") do not need to increase the protocol
|
||||
version. Removals of values with specified defaults from the protocol do not
|
||||
need to increase the protocol version, since the default value can be assumed by
|
||||
compatible enpoints. All other changes to the protocol may require a new version
|
||||
compatible endpoints. All other changes to the protocol may require a new version
|
||||
number.
|
||||
|
||||
### Timing & Backoff
|
||||
|
@ -145,7 +145,7 @@ marketplace](https://marketplace.visualstudio.com/search?target=VSCode&category=
|
||||
* `Ctrl+K, Ctrl+S` opens the key bindings editor.
|
||||
* ``Ctrl+` `` toggles the built-in terminal.
|
||||
* `Ctrl+Shift+M` toggles the problems view (linter warnings, compile errors
|
||||
and warnings). You'll swicth a lot between terminal and problem view during
|
||||
and warnings). You'll switch a lot between terminal and problem view during
|
||||
compilation.
|
||||
* `Alt+O` switches between the source/header file.
|
||||
* `Ctrl+G` jumps to a line.
|
||||
|
Reference in New Issue
Block a user