зеркало из https://github.com/mozilla/gecko-dev.git
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
This commit is contained in:
Родитель
9ba76cd6ad
Коммит
d6cea3eede
|
@ -90,7 +90,7 @@ Actions to take
|
|||
REGRESSION keyword
|
||||
- Set affected status for the releases where the bug appears
|
||||
- Open an issue in the corresponding GitHub project, put the Bugzilla
|
||||
bug number in the title with the prefix ‘Bug’ (i.e. “Bug 99999:
|
||||
bug number in the title with the prefix ‘Bug’ (i.e. “Bug 99999:
|
||||
Regression in foo”)
|
||||
- Add the REGRESSION label to the new issue
|
||||
- Add the link to the GitHub issue into the ‘See Also” field in the
|
||||
|
|
|
@ -116,7 +116,7 @@ These bugs are reviewed in the weekly Regression Triage meeting
|
|||
Automatic Bug Updates
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When a bug is tracked for a release, i.e. the ``tracking_firefoxNN``
|
||||
When a bug is tracked for a release, i.e. the ``tracking_firefoxNN``
|
||||
flag is set to ``+`` or ``blocking`` triage decisions will be overridden,
|
||||
or made as follows:
|
||||
|
||||
|
|
|
@ -90,7 +90,7 @@ explicit approval if:
|
|||
|
||||
| **A)** The bug has a sec-low, sec-moderate, sec-other, or sec-want
|
||||
rating.
|
||||
| **or**
|
||||
| **or**
|
||||
| **B)** The bug is a recent regression on mozilla-central. This means
|
||||
|
||||
- A specific regressing check-in has been identified
|
||||
|
|
|
@ -129,7 +129,7 @@ Editor plugins
|
|||
|
||||
- `clang-format.el <https://raw.githubusercontent.com/llvm-mirror/clang/master/tools/clang-format/clang-format.el>`__
|
||||
(Or install
|
||||
`clang-format <http://melpa.org/#/clang-format>`__ from MELPA)
|
||||
`clang-format <http://melpa.org/#/clang-format>`__ from MELPA)
|
||||
- `google-c-style <http://melpa.org/#/google-c-style>`__ from MELPA
|
||||
|
||||
- `Sublime Text <https://packagecontrol.io/packages/Clang%20Format>`__
|
||||
|
|
|
@ -6,8 +6,8 @@ Script Security
|
|||
This page provides an overview of the script security architecture in
|
||||
Gecko.
|
||||
|
||||
Like any web browser, Gecko can load JavaScript from untrusted and
|
||||
potentially hostile web pages and run it on the user's computer. The
|
||||
Like any web browser, Gecko can load JavaScript from untrusted and
|
||||
potentially hostile web pages and run it on the user's computer. The
|
||||
security model for web content is based on the `same-origin policy
|
||||
<https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy>`__,
|
||||
in which code
|
||||
|
@ -19,7 +19,7 @@ cross-origin, are now mostly standardized across browsers.
|
|||
Gecko has an additional problem, though: while its core is written in
|
||||
C++, the front-end code is written in JavaScript. This JavaScript code,
|
||||
which is commonly referred to as c\ *hrome code*, runs with system
|
||||
privileges. If the code is compromised, the attacker can take over the
|
||||
privileges. If the code is compromised, the attacker can take over the
|
||||
user's computer. Legacy SDK extensions also run with chrome privileges.
|
||||
|
||||
Having the browser front end in JavaScript has benefits: it can be much
|
||||
|
@ -45,19 +45,19 @@ Gecko implements the following security policy:
|
|||
- **Objects that are cross-origin** get highly restricted access to
|
||||
each other, according to the same-origin policy.
|
||||
For example, code served from *https://example.org/* trying to access
|
||||
objects from *https://somewhere-else.org/* will have restricted
|
||||
objects from *https://somewhere-else.org/* will have restricted
|
||||
access.
|
||||
- **Objects in a privileged scope** are allowed complete access to
|
||||
objects in a less privileged scope, but by default they see a
|
||||
`restricted view <#privileged-to-unprivileged-code>`__
|
||||
of such objects, designed to prevent them from being tricked by the
|
||||
untrusted code. An example of this scope is chrome-privileged
|
||||
untrusted code. An example of this scope is chrome-privileged
|
||||
JavaScript accessing web content.
|
||||
- **Objects in a less privileged scope** don't get any access to
|
||||
objects in a more privileged scope, unless the more privileged scope
|
||||
`explicitly clones those objects <#unprivileged-to-privileged-code>`__.
|
||||
An example of this scope is web content accessing objects in a
|
||||
chrome-privileged scope.
|
||||
chrome-privileged scope.
|
||||
|
||||
.. _Compartments:
|
||||
|
||||
|
@ -67,7 +67,7 @@ Compartments
|
|||
Compartments are the foundation for Gecko's script security
|
||||
architecture. A compartment is a specific, separate area of memory. In
|
||||
Gecko, there's a separate compartment for every global object. This
|
||||
means that each global object and the objects associated with it live in
|
||||
means that each global object and the objects associated with it live in
|
||||
their own region of memory.
|
||||
|
||||
.. image:: images/compartments.png
|
||||
|
@ -108,7 +108,7 @@ Same-origin
|
|||
~~~~~~~~~~~
|
||||
|
||||
As we've already seen, the most common scenario for same-origin access
|
||||
is when objects belonging to the same window object interact. This all
|
||||
is when objects belonging to the same window object interact. This all
|
||||
takes place within the same compartment, with no need for security
|
||||
checks or wrappers.
|
||||
|
||||
|
@ -157,9 +157,9 @@ gets an *Xray wrapper* for the object.
|
|||
|
||||
Xrays are designed to prevent untrusted code from confusing trusted code
|
||||
by redefining objects in unexpected ways. For example, privileged code
|
||||
using an Xray to a DOM object sees only the original version of the DOM
|
||||
using an Xray to a DOM object sees only the original version of the DOM
|
||||
object. Any expando properties are not visible, and if any native DOM properties have been
|
||||
redefined, they are not visible in the Xray.
|
||||
redefined, they are not visible in the Xray.
|
||||
|
||||
The privileged code is able to waive Xrays if it wants unfiltered access to the untrusted object.
|
||||
|
||||
|
@ -278,7 +278,7 @@ disabled for web content.
|
|||
|
||||
Expanded principals are useful when you want to give code extra
|
||||
privileges, including cross-origin access, but don't want to give the
|
||||
code full system privileges. For example, expanded principals are used
|
||||
code full system privileges. For example, expanded principals are used
|
||||
in the Add-on SDK to give content scripts cross-domain privileges for a predefined set of
|
||||
domains,
|
||||
and to protect content scripts from access by untrusted web content,
|
||||
|
@ -302,7 +302,7 @@ Principal relationships
|
|||
|
||||
The diagram below summarizes the relationships between the different
|
||||
principals. The arrow connecting principals A and B means "A subsumes
|
||||
B". (A is the start of the arrow, and B is the end.)
|
||||
B". (A is the start of the arrow, and B is the end.)
|
||||
|
||||
.. image:: images/principal-relationships.png
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ Xray Vision
|
|||
Gecko runs JavaScript from a variety of different sources and at a
|
||||
variety of different privilege levels.
|
||||
|
||||
- The JavaScript code that along with the C++ core, implements the
|
||||
- The JavaScript code that along with the C++ core, implements the
|
||||
browser itself is called *chrome code* and runs using system
|
||||
privileges. If chrome-privileged code is compromised, the attacker
|
||||
can take over the user's computer.
|
||||
|
@ -139,7 +139,7 @@ Xrays for DOM objects
|
|||
---------------------
|
||||
|
||||
The primary use of Xray vision is for DOM objects: that is, the
|
||||
objects that represent parts of the web page.
|
||||
objects that represent parts of the web page.
|
||||
|
||||
In Gecko, DOM objects have a dual representation: the canonical
|
||||
representation is in C++, and this is reflected into JavaScript for the
|
||||
|
|
|
@ -19,9 +19,9 @@ The worker’s life cycle is maintained by a status machine in the WorkerPrivate
|
|||
Following we briefly describe what is done for each status.
|
||||
|
||||
|
||||
### Pending:
|
||||
### Pending:
|
||||
|
||||
This is the initial status of a Worker.
|
||||
This is the initial status of a Worker.
|
||||
|
||||
Worker’s initialization is done in this status in the parent(main or the parent worker) and worker thread.
|
||||
|
||||
|
@ -34,9 +34,9 @@ Worker’s initialization starts from its parent thread, which includes
|
|||
5. Connect debugger
|
||||
6. Dispatch CompileScriptRunnable to the worker thread
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
When WorkerThreadPrimaryRunnable starts executing on the worker thread, it continues the initialization on the worker thread, which includes
|
||||
When WorkerThreadPrimaryRunnable starts executing on the worker thread, it continues the initialization on the worker thread, which includes
|
||||
|
||||
1. Build the connection between WorkerPrivate and the worker thread. Then moving the WorkerPrivate::mPreStartRunnables to the worker thread’s event queue.
|
||||
2. Initialize the PerformanceStorage for the Worker.
|
||||
|
@ -60,12 +60,12 @@ Once the Worker gets into “Running”,
|
|||
2. Create sync-eventLoop to make the worker thread to wait for another thread's execution.
|
||||
3. Dispatching events to WorkerGlobalScope to trigger event callbacks defined in the script.
|
||||
|
||||
We will talk about WorkerRef, Sync-EventLoop in detail later.
|
||||
We will talk about WorkerRef, Sync-EventLoop in detail later.
|
||||
|
||||
|
||||
### Closing:
|
||||
|
||||
This is a special status for DedicatedWorker and SharedWorker when DedicateWorkerGlobalScope.close()/SharedWorkerGlobalScope.close() is called.
|
||||
This is a special status for DedicatedWorker and SharedWorker when DedicateWorkerGlobalScope.close()/SharedWorkerGlobalScope.close() is called.
|
||||
|
||||
When Worker enters into the “Closing” status,
|
||||
|
||||
|
@ -92,7 +92,7 @@ So the WorkerRef holders and children Workers will start the shutdown jobs
|
|||
|
||||
Once all sync-eventLoops are closed,
|
||||
|
||||
1. Disconnect the EventTarget/WebTaskScheduler of the WorkerGlobalScope
|
||||
1. Disconnect the EventTarget/WebTaskScheduler of the WorkerGlobalScope
|
||||
|
||||
|
||||
### Killing:
|
||||
|
@ -133,7 +133,7 @@ The WorkerPrivate is supposed to be released after its self-reference is nullifi
|
|||
|
||||
Normally, there are four situations making a Worker get into shutdown.
|
||||
|
||||
1. Worker is GC/CCed.
|
||||
1. Worker is GC/CCed.
|
||||
|
||||
1. Navigating to another page.
|
||||
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
|
|||
|
||||
### WeakWorkerRef
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
WeakWorkerRef is ref-counted, but not thread-safe.
|
||||
|
||||
|
@ -189,7 +189,7 @@ Unlike WeakWorkerRef, StrongWorkerRef does not release its internal reference to
|
|||
|
||||
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.
|
||||
|
||||
StrongWorkerRef also blocks the GC/CC a Worker. Once there is a StrongWorkerRef to the Worker, GC/CC will not collect the Worker.
|
||||
StrongWorkerRef also blocks the GC/CC a Worker. Once there is a StrongWorkerRef to the Worker, GC/CC will not collect the Worker.
|
||||
|
||||
StrongWorkerRef is ref-counted, but not thread-safe.
|
||||
|
||||
|
@ -207,7 +207,7 @@ ThreadSafeWorkerRef is ref-counted and thread-safe.
|
|||
|
||||
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)
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
IPCWorkerRef is ref-counted, but not thread-safe.
|
||||
|
||||
|
@ -218,7 +218,7 @@ Following is a table for the comparison between WorkerRefs
|
|||
| | WeakWorkerRef | StrongWorkerRef | ThreadSafeWorkerRef | IPCWorkerRef |
|
||||
| Holder thread | Worker thread | Worker thread | Any thread | Worker thread |
|
||||
| Callback execution thread | Worker thread | Worker thread | Worker thread | Worker thread |
|
||||
| Block Worker’s shutdown | No | Yes | Yes | Yes |
|
||||
| Block Worker’s shutdown | No | Yes | Yes | Yes |
|
||||
| Block GC a Worker | No | Yes | Yes | No |
|
||||
|
||||
|
||||
|
|
|
@ -227,7 +227,7 @@ touch event.
|
|||
|
||||
Now let us add some async scrolling to this example. Say that the user
|
||||
additionally scrolls the document by another 10 pixels asynchronously
|
||||
(i.e. only on the compositor thread), and then does the same touch
|
||||
(i.e. only on the compositor thread), and then does the same touch
|
||||
event. The same input event is generated by the hardware, and as before,
|
||||
the document will deliver the touch event to the div at y=300. However,
|
||||
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.
|
|||
Because the cross-thread messaging is asynchronous, reconciling the two
|
||||
types of scroll changes is a tricky problem. Our design solves this
|
||||
using various flags and generation counters. The general heuristic we
|
||||
have is that content-driven scroll position changes (e.g. scrollTo from
|
||||
have is that content-driven scroll position changes (e.g. scrollTo from
|
||||
JS) are never lost. For instance, if the user is doing an async scroll
|
||||
with their finger and content does a scrollTo in the middle, then some
|
||||
of the async scroll would occur before the “jump” and the rest after the
|
||||
|
|
|
@ -114,7 +114,7 @@ Layers
|
|||
Rendering each layer
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Tiling vs. Buffer Rotation vs. Full paint
|
||||
Tiling vs. Buffer Rotation vs. Full paint
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Compositing for the final result
|
||||
|
|
|
@ -31,7 +31,7 @@ infrastructure.
|
|||
|
||||
- Tiling v1 (April 2012 - Bug 739679) Originally done for Fennec. This
|
||||
was done to avoid situations where we had to do a bunch of work for
|
||||
scrolling a small amount. i.e. buffer rotation. It allowed us to have
|
||||
scrolling a small amount. i.e. buffer rotation. It allowed us to have
|
||||
a variety of interesting features like progressive painting and lower
|
||||
resolution painting.
|
||||
|
||||
|
|
|
@ -486,7 +486,7 @@ to a bare :python:`COPY()`.
|
|||
Plural Strings
|
||||
--------------
|
||||
|
||||
Migrating plural strings from `.properties` files usually involves two
|
||||
Migrating plural strings from `.properties` files usually involves two
|
||||
Transforms from :python:`fluent.migrate.transforms`: the
|
||||
:python:`REPLACE_IN_TEXT` Transform takes TextElements as input, making it
|
||||
possible to pass it as the foreach function of the :python:`PLURALS` Transform.
|
||||
|
|
|
@ -79,7 +79,7 @@ to do your build:
|
|||
|
||||
This is because, starting from Mojave, headers are no longer
|
||||
installed in ``/usr/include``. Refer the `release
|
||||
notes <https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes>`__ under
|
||||
notes <https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes>`__ under
|
||||
Command Line Tools -> New Features
|
||||
|
||||
The release notes also states that this compatibility package will no longer be provided in the near
|
||||
|
|
|
@ -264,7 +264,7 @@ the extension.
|
|||
|
||||
The type of ``message`` will be ``JSONObject`` when the extension sends
|
||||
a javascript object, but could also be a primitive type if the extension
|
||||
sends one, e.g. for
|
||||
sends one, e.g. for
|
||||
|
||||
.. code:: javascript
|
||||
|
||||
|
@ -372,7 +372,7 @@ and then using it when needed.
|
|||
}
|
||||
|
||||
For example, let’s send a message to the extension every time the user
|
||||
long presses on a key on the virtual keyboard, e.g. on the back button.
|
||||
long presses on a key on the virtual keyboard, e.g. on the back button.
|
||||
|
||||
.. code:: java
|
||||
|
||||
|
|
|
@ -90,7 +90,7 @@ Once you've done that, you can create a new server as follows:
|
|||
You can also pass in a numeric port argument to the ``start()`` method,
|
||||
but we strongly suggest you don't do it. Using a dynamic port allow us
|
||||
to run your test in parallel with other tests which reduces wait times
|
||||
and makes everybody happy. If you really have to use a hardcoded port,
|
||||
and makes everybody happy. If you really have to use a hardcoded port,
|
||||
you will have to annotate your test in the xpcshell manifest file with
|
||||
``run-sequentially = REASON``.
|
||||
However, this should only be used as the last possible option.
|
||||
|
@ -271,7 +271,7 @@ without state accidentally bleeding between unrelated handlers.
|
|||
|
||||
.. note::
|
||||
|
||||
**Note:** State saved by this method is specific to the HTTP path,
|
||||
State saved by this method is specific to the HTTP path,
|
||||
excluding query string and hash reference. ``/counter``,
|
||||
``/counter?foo``, and ``/counter?bar#baz`` all share the same state
|
||||
for the purposes of these methods. (Indeed, non-shared state would be
|
||||
|
@ -280,7 +280,7 @@ without state accidentally bleeding between unrelated handlers.
|
|||
|
||||
.. note::
|
||||
|
||||
**Note:** The predefined ``__LOCATION__`` state
|
||||
The predefined ``__LOCATION__`` state
|
||||
contains the native path of the SJS file itself. You can pass the
|
||||
result directly to the ``nsILocalFile.initWithPath()``. Example:
|
||||
``thisSJSfile.initWithPath(getState('__LOCATION__'));``
|
||||
|
|
|
@ -191,7 +191,7 @@ with a URL. Do not modify this value.
|
|||
|
||||
.. warning::
|
||||
|
||||
Since Firefox 64, the *"ASan Crash Reporter"* feature is no longer
|
||||
Since Firefox 64, the *"ASan Crash Reporter"* feature is no longer
|
||||
listed in ``about:support``
|
||||
|
||||
Will there be support for Mac?
|
||||
|
|
Загрузка…
Ссылка в новой задаче