Skip to content

Commit 2cc79f5

Browse files
committedDec 3, 2023
Bug 1519636 - Remove nbsp in the doc r=firefox-source-docs-reviewers,geckoview-reviewers,ahal,m_kato
Differential Revision: https://phabricator.services.mozilla.com/D194782
1 parent f2306fd commit 2cc79f5

File tree

15 files changed

+42
-42
lines changed

15 files changed

+42
-42
lines changed
 

‎docs/bug-mgmt/policies/regressions-github.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ Actions to take
9090
REGRESSION keyword
9191
- Set affected status for the releases where the bug appears
9292
- Open an issue in the corresponding GitHub project, put the Bugzilla
93-
bug number in the title with the prefix ‘Bug’ (i.e. “Bug 99999:
93+
bug number in the title with the prefix ‘Bug’ (i.e. “Bug 99999:
9494
Regression in foo”)
9595
- Add the REGRESSION label to the new issue
9696
- Add the link to the GitHub issue into the ‘See Also” field in the

‎docs/bug-mgmt/policies/triage-bugzilla.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -116,7 +116,7 @@ These bugs are reviewed in the weekly Regression Triage meeting
116116
Automatic Bug Updates
117117
~~~~~~~~~~~~~~~~~~~~~
118118

119-
When a bug is tracked for a release, i.e. the ``tracking_firefoxNN``
119+
When a bug is tracked for a release, i.e. the ``tracking_firefoxNN``
120120
flag is set to ``+`` or ``blocking`` triage decisions will be overridden,
121121
or made as follows:
122122

‎docs/bug-mgmt/processes/security-approval.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ explicit approval if:
9090

9191
| **A)** The bug has a sec-low, sec-moderate, sec-other, or sec-want
9292
rating.
93-
|    **or**
93+
| **or**
9494
| **B)** The bug is a recent regression on mozilla-central. This means
9595
9696
- A specific regressing check-in has been identified

‎docs/code-quality/coding-style/format_cpp_code_with_clang-format.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -129,7 +129,7 @@ Editor plugins
129129

130130
- `clang-format.el <https://raw.githubusercontent.com/llvm-mirror/clang/master/tools/clang-format/clang-format.el>`__
131131
(Or install
132-
`clang-format <http://melpa.org/#/clang-format>`__ from MELPA)
132+
`clang-format <http://melpa.org/#/clang-format>`__ from MELPA)
133133
- `google-c-style <http://melpa.org/#/google-c-style>`__ from MELPA
134134

135135
- `Sublime Text <https://packagecontrol.io/packages/Clang%20Format>`__

‎dom/docs/scriptSecurity/index.rst

+12-12
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,8 @@ Script Security
66
This page provides an overview of the script security architecture in
77
Gecko.
88

9-
Like any web browser, Gecko can load JavaScript from untrusted and
10-
potentially hostile web pages and run it on the user's computer. The
9+
Like any web browser, Gecko can load JavaScript from untrusted and
10+
potentially hostile web pages and run it on the user's computer. The
1111
security model for web content is based on the `same-origin policy
1212
<https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy>`__,
1313
in which code
@@ -19,7 +19,7 @@ cross-origin, are now mostly standardized across browsers.
1919
Gecko has an additional problem, though: while its core is written in
2020
C++, the front-end code is written in JavaScript. This JavaScript code,
2121
which is commonly referred to as c\ *hrome code*, runs with system
22-
privileges. If the code is compromised, the attacker can take over the
22+
privileges. If the code is compromised, the attacker can take over the
2323
user's computer. Legacy SDK extensions also run with chrome privileges.
2424

2525
Having the browser front end in JavaScript has benefits: it can be much
@@ -45,19 +45,19 @@ Gecko implements the following security policy:
4545
- **Objects that are cross-origin** get highly restricted access to
4646
each other, according to the same-origin policy.
4747
For example, code served from *https://example.org/* trying to access
48-
objects from *https://somewhere-else.org/* will have restricted
48+
objects from *https://somewhere-else.org/* will have restricted
4949
access.
5050
- **Objects in a privileged scope** are allowed complete access to
5151
objects in a less privileged scope, but by default they see a
5252
`restricted view <#privileged-to-unprivileged-code>`__
5353
of such objects, designed to prevent them from being tricked by the
54-
untrusted code. An example of this scope is chrome-privileged
54+
untrusted code. An example of this scope is chrome-privileged
5555
JavaScript accessing web content.
5656
- **Objects in a less privileged scope** don't get any access to
5757
objects in a more privileged scope, unless the more privileged scope
5858
`explicitly clones those objects <#unprivileged-to-privileged-code>`__.
5959
An example of this scope is web content accessing objects in a
60-
chrome-privileged scope. 
60+
chrome-privileged scope.
6161

6262
.. _Compartments:
6363

@@ -67,7 +67,7 @@ Compartments
6767
Compartments are the foundation for Gecko's script security
6868
architecture. A compartment is a specific, separate area of memory. In
6969
Gecko, there's a separate compartment for every global object. This
70-
means that each global object and the objects associated with it live in
70+
means that each global object and the objects associated with it live in
7171
their own region of memory.
7272

7373
.. image:: images/compartments.png
@@ -108,7 +108,7 @@ Same-origin
108108
~~~~~~~~~~~
109109

110110
As we've already seen, the most common scenario for same-origin access
111-
is when objects belonging to the same window object interact. This all
111+
is when objects belonging to the same window object interact. This all
112112
takes place within the same compartment, with no need for security
113113
checks or wrappers.
114114

@@ -157,9 +157,9 @@ gets an *Xray wrapper* for the object.
157157

158158
Xrays are designed to prevent untrusted code from confusing trusted code
159159
by redefining objects in unexpected ways. For example, privileged code
160-
using an Xray to a DOM object sees only the original version of the DOM
160+
using an Xray to a DOM object sees only the original version of the DOM
161161
object. Any expando properties are not visible, and if any native DOM properties have been
162-
redefined, they are not visible in the Xray.
162+
redefined, they are not visible in the Xray.
163163

164164
The privileged code is able to waive Xrays if it wants unfiltered access to the untrusted object.
165165

@@ -278,7 +278,7 @@ disabled for web content.
278278

279279
Expanded principals are useful when you want to give code extra
280280
privileges, including cross-origin access, but don't want to give the
281-
code full system privileges. For example, expanded principals are used
281+
code full system privileges. For example, expanded principals are used
282282
in the Add-on SDK to give content scripts cross-domain privileges for a predefined set of
283283
domains,
284284
and to protect content scripts from access by untrusted web content,
@@ -302,7 +302,7 @@ Principal relationships
302302

303303
The diagram below summarizes the relationships between the different
304304
principals. The arrow connecting principals A and B means "A subsumes
305-
B".  (A is the start of the arrow, and B is the end.)
305+
B". (A is the start of the arrow, and B is the end.)
306306

307307
.. image:: images/principal-relationships.png
308308

‎dom/docs/scriptSecurity/xray_vision.rst

+2-2
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ Xray Vision
1010
Gecko runs JavaScript from a variety of different sources and at a
1111
variety of different privilege levels.
1212

13-
- The JavaScript code that along with the C++ core, implements the
13+
- The JavaScript code that along with the C++ core, implements the
1414
browser itself is called *chrome code* and runs using system
1515
privileges. If chrome-privileged code is compromised, the attacker
1616
can take over the user's computer.
@@ -139,7 +139,7 @@ Xrays for DOM objects
139139
---------------------
140140

141141
The primary use of Xray vision is for DOM objects: that is, the
142-
objects that represent parts of the web page.
142+
objects that represent parts of the web page.
143143

144144
In Gecko, DOM objects have a dual representation: the canonical
145145
representation is in C++, and this is reflected into JavaScript for the

‎dom/docs/workersAndStorage/WorkerLifeCycleAndWorkerRefs.md

+12-12
Original file line numberDiff line numberDiff line change
@@ -19,9 +19,9 @@ The worker’s life cycle is maintained by a status machine in the WorkerPrivate
1919
Following we briefly describe what is done for each status.
2020

2121

22-
### Pending: 
22+
### Pending:
2323

24-
This is the initial status of a Worker. 
24+
This is the initial status of a Worker.
2525

2626
Worker’s initialization is done in this status in the parent(main or the parent worker) and worker thread.
2727

@@ -34,9 +34,9 @@ Worker’s initialization starts from its parent thread, which includes
3434
5. Connect debugger
3535
6. Dispatch CompileScriptRunnable to the worker thread
3636

37-
Before the Worker thread starts running runnables, a Worker could have already been exposed to its parent window/worker. So the parent window/worker can send messages to the worker through the postMessage() method. If the Worker is not in the “Running” status yet, these runnables would be kept in WorkerPrivate::mPreStartRunnables. 
37+
Before the Worker thread starts running runnables, a Worker could have already been exposed to its parent window/worker. So the parent window/worker can send messages to the worker through the postMessage() method. If the Worker is not in the “Running” status yet, these runnables would be kept in WorkerPrivate::mPreStartRunnables.
3838

39-
When WorkerThreadPrimaryRunnable starts executing on the worker thread, it continues the initialization on the worker thread, which includes  
39+
When WorkerThreadPrimaryRunnable starts executing on the worker thread, it continues the initialization on the worker thread, which includes
4040

4141
1. Build the connection between WorkerPrivate and the worker thread. Then moving the WorkerPrivate::mPreStartRunnables to the worker thread’s event queue.
4242
2. Initialize the PerformanceStorage for the Worker.
@@ -60,12 +60,12 @@ Once the Worker gets into “Running”,
6060
2. Create sync-eventLoop to make the worker thread to wait for another thread's execution.
6161
3. Dispatching events to WorkerGlobalScope to trigger event callbacks defined in the script.
6262

63-
We will talk about WorkerRef, Sync-EventLoop in detail later. 
63+
We will talk about WorkerRef, Sync-EventLoop in detail later.
6464

6565

6666
### Closing:
6767

68-
This is a special status for DedicatedWorker and SharedWorker when DedicateWorkerGlobalScope.close()/SharedWorkerGlobalScope.close() is called. 
68+
This is a special status for DedicatedWorker and SharedWorker when DedicateWorkerGlobalScope.close()/SharedWorkerGlobalScope.close() is called.
6969

7070
When Worker enters into the “Closing” status,
7171

@@ -92,7 +92,7 @@ So the WorkerRef holders and children Workers will start the shutdown jobs
9292

9393
Once all sync-eventLoops are closed,
9494

95-
1.  Disconnect the EventTarget/WebTaskScheduler of the WorkerGlobalScope
95+
1. Disconnect the EventTarget/WebTaskScheduler of the WorkerGlobalScope
9696

9797

9898
### Killing:
@@ -133,7 +133,7 @@ The WorkerPrivate is supposed to be released after its self-reference is nullifi
133133

134134
Normally, there are four situations making a Worker get into shutdown.
135135

136-
1. Worker is GC/CCed. 
136+
1. Worker is GC/CCed.
137137

138138
1. Navigating to another page.
139139
2. Worker is idle for a while. (Notice that idle is not a status of Worker, it is a condition in “Running” status)
@@ -176,7 +176,7 @@ According to the following requirements, four types of WorkerRefs are introduced
176176

177177
### WeakWorkerRef
178178

179-
WeakWorkerRef, as its name, is a “Weak” reference since WeakWorkerRef releases the internal reference to the Worker immediately after WeakWorkerRef’s registered callback execution completes. Therefore, WeakWorkerRef does not block the Worker’s shutdown. In addition, holding a WeakWorkerRef would not block GC/CC the Worker. This means a Worker will be considered to be cycle-collected even if there are WeakWorkerRefs to the Worker. 
179+
WeakWorkerRef, as its name, is a “Weak” reference since WeakWorkerRef releases the internal reference to the Worker immediately after WeakWorkerRef’s registered callback execution completes. Therefore, WeakWorkerRef does not block the Worker’s shutdown. In addition, holding a WeakWorkerRef would not block GC/CC the Worker. This means a Worker will be considered to be cycle-collected even if there are WeakWorkerRefs to the Worker.
180180

181181
WeakWorkerRef is ref-counted, but not thread-safe.
182182

@@ -189,7 +189,7 @@ Unlike WeakWorkerRef, StrongWorkerRef does not release its internal reference to
189189

190190
When using the StrongWorkerRef, resource cleanup might involve multiple threads and asynchronous behavior. StrongWorkerRef release timing becomes crucial not to cause memory problems, such as UAF or leaking. StrongWorkerRef must be released. Otherwise, a shutdown hang would not be a surprise.
191191

192-
StrongWorkerRef also blocks the GC/CC a Worker. Once there is a StrongWorkerRef to the Worker, GC/CC will not collect the Worker. 
192+
StrongWorkerRef also blocks the GC/CC a Worker. Once there is a StrongWorkerRef to the Worker, GC/CC will not collect the Worker.
193193

194194
StrongWorkerRef is ref-counted, but not thread-safe.
195195

@@ -207,7 +207,7 @@ ThreadSafeWorkerRef is ref-counted and thread-safe.
207207

208208
IPCWorkerRef is a special WorkerRef for IPC actors which binds its life-cycle with Worker’s shutdown notification. (In our current codebase, Cache API and Client API uses IPCWorkerRef)
209209

210-
Because some IPC shutdown needs to be in a special sequence during the Worker's shutdown. However, to make these IPC shutdown needs to ensure the Worker is kept alive, so IPCWorkerRef blocks the Worker's shutdown. But IPC shutdown no need to block GC/CC a Worker.   
210+
Because some IPC shutdown needs to be in a special sequence during the Worker's shutdown. However, to make these IPC shutdown needs to ensure the Worker is kept alive, so IPCWorkerRef blocks the Worker's shutdown. But IPC shutdown no need to block GC/CC a Worker.
211211

212212
IPCWorkerRef is ref-counted, but not thread-safe.
213213

@@ -218,7 +218,7 @@ Following is a table for the comparison between WorkerRefs
218218
| | WeakWorkerRef | StrongWorkerRef | ThreadSafeWorkerRef | IPCWorkerRef |
219219
| Holder thread | Worker thread | Worker thread | Any thread | Worker thread |
220220
| Callback execution thread | Worker thread | Worker thread | Worker thread | Worker thread |
221-
| Block Worker’s shutdown  | No | Yes | Yes | Yes |
221+
| Block Worker’s shutdown | No | Yes | Yes | Yes |
222222
| Block GC a Worker | No | Yes | Yes | No |
223223

224224

‎gfx/docs/AsyncPanZoom.rst

+2-2
Original file line numberDiff line numberDiff line change
@@ -227,7 +227,7 @@ touch event.
227227

228228
Now let us add some async scrolling to this example. Say that the user
229229
additionally scrolls the document by another 10 pixels asynchronously
230-
(i.e. only on the compositor thread), and then does the same touch
230+
(i.e. only on the compositor thread), and then does the same touch
231231
event. The same input event is generated by the hardware, and as before,
232232
the document will deliver the touch event to the div at y=300. However,
233233
visually, the document is scrolled by an additional 10 pixels so this
@@ -260,7 +260,7 @@ compositor thread, so that the visual display updates in response.
260260
Because the cross-thread messaging is asynchronous, reconciling the two
261261
types of scroll changes is a tricky problem. Our design solves this
262262
using various flags and generation counters. The general heuristic we
263-
have is that content-driven scroll position changes (e.g. scrollTo from
263+
have is that content-driven scroll position changes (e.g. scrollTo from
264264
JS) are never lost. For instance, if the user is doing an async scroll
265265
with their finger and content does a scrollTo in the middle, then some
266266
of the async scroll would occur before the “jump” and the rest after the

‎gfx/docs/GraphicsOverview.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -114,7 +114,7 @@ Layers
114114
Rendering each layer
115115
~~~~~~~~~~~~~~~~~~~~
116116

117-
Tiling vs. Buffer Rotation vs. Full paint
117+
Tiling vs. Buffer Rotation vs. Full paint
118118
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
119119

120120
Compositing for the final result

‎gfx/docs/LayersHistory.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ infrastructure.
3131

3232
- Tiling v1 (April 2012 - Bug 739679) Originally done for Fennec. This
3333
was done to avoid situations where we had to do a bunch of work for
34-
scrolling a small amount. i.e. buffer rotation. It allowed us to have
34+
scrolling a small amount. i.e. buffer rotation. It allowed us to have
3535
a variety of interesting features like progressive painting and lower
3636
resolution painting.
3737

‎intl/l10n/docs/migrations/legacy.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -486,7 +486,7 @@ to a bare :python:`COPY()`.
486486
Plural Strings
487487
--------------
488488

489-
Migrating plural strings from `.properties` files usually involves two
489+
Migrating plural strings from `.properties` files usually involves two
490490
Transforms from :python:`fluent.migrate.transforms`: the
491491
:python:`REPLACE_IN_TEXT` Transform takes TextElements as input, making it
492492
possible to pass it as the foreach function of the :python:`PLURALS` Transform.

‎js/src/doc/build.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ to do your build:
7979

8080
This is because, starting from Mojave, headers are no longer
8181
installed in ``/usr/include``. Refer the `release
82-
notes <https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes>`__  under
82+
notes <https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes>`__ under
8383
Command Line Tools -> New Features
8484

8585
The release notes also states that this compatibility package will no longer be provided in the near

‎mobile/android/docs/geckoview/consumer/web-extensions.rst

+2-2
Original file line numberDiff line numberDiff line change
@@ -264,7 +264,7 @@ the extension.
264264

265265
The type of ``message`` will be ``JSONObject`` when the extension sends
266266
a javascript object, but could also be a primitive type if the extension
267-
sends one, e.g. for
267+
sends one, e.g. for
268268

269269
.. code:: javascript
270270
@@ -372,7 +372,7 @@ and then using it when needed.
372372
}
373373
374374
For example, let’s send a message to the extension every time the user
375-
long presses on a key on the virtual keyboard, e.g. on the back button.
375+
long presses on a key on the virtual keyboard, e.g. on the back button.
376376

377377
.. code:: java
378378

‎netwerk/docs/http_server_for_testing.rst

+3-3
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ Once you've done that, you can create a new server as follows:
9090
You can also pass in a numeric port argument to the ``start()`` method,
9191
but we strongly suggest you don't do it. Using a dynamic port allow us
9292
to run your test in parallel with other tests which reduces wait times
93-
and makes everybody happy.  If you really have to use a hardcoded port,
93+
and makes everybody happy. If you really have to use a hardcoded port,
9494
you will have to annotate your test in the xpcshell manifest file with
9595
``run-sequentially = REASON``.
9696
However, this should only be used as the last possible option.
@@ -271,7 +271,7 @@ without state accidentally bleeding between unrelated handlers.
271271

272272
.. note::
273273

274-
**Note:** State saved by this method is specific to the HTTP path,
274+
State saved by this method is specific to the HTTP path,
275275
excluding query string and hash reference. ``/counter``,
276276
``/counter?foo``, and ``/counter?bar#baz`` all share the same state
277277
for the purposes of these methods. (Indeed, non-shared state would be
@@ -280,7 +280,7 @@ without state accidentally bleeding between unrelated handlers.
280280

281281
.. note::
282282

283-
**Note:** The predefined ``__LOCATION__`` state
283+
The predefined ``__LOCATION__`` state
284284
contains the native path of the SJS file itself. You can pass the
285285
result directly to the ``nsILocalFile.initWithPath()``. Example:
286286
``thisSJSfile.initWithPath(getState('__LOCATION__'));``

‎tools/sanitizer/docs/asan_nightly.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -191,7 +191,7 @@ with a URL. Do not modify this value.
191191

192192
.. warning::
193193

194-
Since Firefox 64, the *"ASan Crash Reporter"*  feature is no longer
194+
Since Firefox 64, the *"ASan Crash Reporter"* feature is no longer
195195
listed in ``about:support``
196196

197197
Will there be support for Mac?

0 commit comments

Comments
 (0)
Failed to load comments.