зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1444628 - Fix a bunch of typo in the doc r=ahal
MozReview-Commit-ID: SNXsViVUm0 --HG-- extra : rebase_source : d1a73dd5399854c0ec28087b207bb1b1d4bb9c02
This commit is contained in:
Родитель
7d1d15228b
Коммит
06b7836c7e
|
@ -33,7 +33,7 @@ renderLayers, hasLayers, docShellIsActive
|
|||
For non-remote ``<xul:browser>``'s, ``hasLayers`` returns the value for ``docShellIsActive``.
|
||||
|
||||
``docShellIsActive``
|
||||
For remote ``<xul:browser>``'s, setting ``docShellIsActive`` to ``true`` also sets ``renderLayers`` to true, and then sends a message to the content process to set its top-level docShell active state to ``true``. Similarly, setting ``docShellIsActive`` to ``false`` also sets ``renderLayers`` to false, and then sends a message ot the content process to set its top-level docShell active state to ``false``.
|
||||
For remote ``<xul:browser>``'s, setting ``docShellIsActive`` to ``true`` also sets ``renderLayers`` to true, and then sends a message to the content process to set its top-level docShell active state to ``true``. Similarly, setting ``docShellIsActive`` to ``false`` also sets ``renderLayers`` to false, and then sends a message to the content process to set its top-level docShell active state to ``false``.
|
||||
|
||||
For non-remote ``<xul:browser>``'s, ``docShellIsActive`` forwards to the ``isActive`` property on the ``<xul:browser>``'s top-level docShell.
|
||||
|
||||
|
@ -230,4 +230,4 @@ Logging
|
|||
|
||||
The async tab switcher has some logging capabilities that make it easier to debug and reason about its behaviour. Setting the hidden ``browser.tabs.remote.logSwitchTiming`` pref to true will put logging into the Browser Console.
|
||||
|
||||
Alternatively, setting the ``useDumpForLogging`` property to true within the source code of the tab switcher will dump those logs to stdout.
|
||||
Alternatively, setting the ``useDumpForLogging`` property to true within the source code of the tab switcher will dump those logs to stdout.
|
||||
|
|
|
@ -103,7 +103,7 @@ I/O.
|
|||
|
||||
For more on how ``moz.build`` files work, see :ref:`mozbuild-files`.
|
||||
|
||||
Phase 3: Invokation of the Build Backend
|
||||
Phase 3: Invocation of the Build Backend
|
||||
========================================
|
||||
|
||||
When most people think of the build system, they think of phase 3. This is
|
||||
|
|
|
@ -51,7 +51,7 @@ can point to the directory via
|
|||
Instructions for multi-locale builds
|
||||
------------------------------------
|
||||
|
||||
If you want to create a single build with mutliple locales, you will do
|
||||
If you want to create a single build with multiple locales, you will do
|
||||
|
||||
#. Create a build and package
|
||||
|
||||
|
|
|
@ -107,7 +107,7 @@ the build system.
|
|||
When Python compiles a ``.py`` file to bytecode, it writes out a
|
||||
``.pyc`` file so it doesn't have to perform this compilation again.
|
||||
It puts these ``.pyc`` files alongside the ``.pyc`` file. Python
|
||||
provides very little control for determing where these ``.pyc`` files
|
||||
provides very little control for determining where these ``.pyc`` files
|
||||
go, even in Python 3 (which offers customer importers).
|
||||
|
||||
With ``.pth`` files pointing back to directories in the source tree
|
||||
|
|
|
@ -122,7 +122,7 @@ Each `PushRegistration` corresponds to a unique *uaid* (User-Agent ID) on the
|
|||
autopush server. Each *uaid* is long-lived; a healthy client will maintain the
|
||||
same *uaid* until the client's configuration changes or the service expires the
|
||||
registration due to inactivity or an unexpected server event. Each
|
||||
`PushSubscription` is associated to a given *uaid* and correponds to a unique
|
||||
`PushSubscription` is associated to a given *uaid* and corresponds to a unique
|
||||
(per-*uaid*) *chid* (Channel ID) on the autopush server. An individual *chid*
|
||||
is potentially long-lived, but clients must expect the service to expire *chid*s
|
||||
as part of regular maintenance. The `PushManager` uses an `AutopushClient`
|
||||
|
|
|
@ -142,7 +142,7 @@ options. A few questions to consider:
|
|||
* Is this one of a few related tasks, or will you need to generate a large
|
||||
set of tasks using some programmatic means (for example, chunking)?
|
||||
|
||||
* How is the task actually excuted? Mozharness? Mach?
|
||||
* How is the task actually executed? Mozharness? Mach?
|
||||
|
||||
* What kind of environment does the task require?
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ Running a process
|
|||
mozprocess consists of two classes: ProcessHandler inherits from ProcessHandlerMixin.
|
||||
|
||||
Let's see how to run a process.
|
||||
First, the class should be instanciated with at least one argument which is a command (or a list formed by the command followed by its arguments).
|
||||
First, the class should be instantiated with at least one argument which is a command (or a list formed by the command followed by its arguments).
|
||||
Then the process can be launched using the *run()* method.
|
||||
Finally the *wait()* method will wait until end of execution.
|
||||
|
||||
|
@ -207,7 +207,7 @@ Except on Windows, you can specify the signal with which to kill method the proc
|
|||
End of execution
|
||||
````````````````
|
||||
|
||||
You can provide a function or a list of functions to call at the end of the process using the initilization parameter *onFinish*.
|
||||
You can provide a function or a list of functions to call at the end of the process using the initialization parameter *onFinish*.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
@ -297,7 +297,7 @@ By default the *ignore_children* option is False. In that case, killing the main
|
|||
print("kill")
|
||||
p.kill()
|
||||
|
||||
If *ignore_children* is set to *True*, killing will apply only to the main process that will wait children end of execution before stoping (join).
|
||||
If *ignore_children* is set to *True*, killing will apply only to the main process that will wait children end of execution before stopping (join).
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
|
|
@ -63,7 +63,7 @@ Release History
|
|||
|
||||
* Upgrade setuptools to 19.6
|
||||
|
||||
* Supress any errors from `unset` on different shells (:pull:`843`)
|
||||
* Suppress any errors from `unset` on different shells (:pull:`843`)
|
||||
|
||||
* Normalize letter case for prefix path checking. Fixes :issue:`837`
|
||||
|
||||
|
@ -355,7 +355,7 @@ Release History
|
|||
------------------
|
||||
|
||||
* Updated to pip 1.3.1 that fixed a major backward incompatible change of
|
||||
parsing URLs to externally hosted packages that got accidentily included
|
||||
parsing URLs to externally hosted packages that got accidentally included
|
||||
in pip 1.3.
|
||||
|
||||
1.9 (2013-03-07)
|
||||
|
|
|
@ -104,7 +104,7 @@ Here's example usage of the module::
|
|||
Object model compatibility
|
||||
>>>>>>>>>>>>>>>>>>>>>>>>>>
|
||||
|
||||
Python 3 renamed the attributes of several intepreter data structures. The
|
||||
Python 3 renamed the attributes of several interpreter data structures. The
|
||||
following accessors are available. Note that the recommended way to inspect
|
||||
functions and methods is the stdlib :mod:`py3:inspect` module.
|
||||
|
||||
|
@ -459,7 +459,7 @@ For the most part, :mod:`six.moves` aliases are the names of the modules in
|
|||
Python 3. When the new Python 3 name is a package, the components of the name
|
||||
are separated by underscores. For example, ``html.parser`` becomes
|
||||
``html_parser``. In some cases where several modules have been combined, the
|
||||
Python 2 name is retained. This is so the appropiate modules can be found when
|
||||
Python 2 name is retained. This is so the appropriate modules can be found when
|
||||
running on Python 2. For example, ``BaseHTTPServer`` which is in
|
||||
``http.server`` in Python 3 is aliased as ``BaseHTTPServer``.
|
||||
|
||||
|
|
|
@ -179,7 +179,7 @@ Simple key-value pairs are of the form::
|
|||
|
||||
key: value
|
||||
|
||||
Note that unlike ini files, only `:` is a valid seperator; `=` will
|
||||
Note that unlike ini files, only `:` is a valid separator; `=` will
|
||||
not work as expected. Key-value pairs may also have conditional
|
||||
values of the form::
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ Stash
|
|||
|
||||
Object for storing cross-request state. This is unusual in that keys
|
||||
must be UUIDs, in order to prevent different clients setting the same
|
||||
key, and values are write-once, read-once to minimise the chances of
|
||||
key, and values are write-once, read-once to minimize the chances of
|
||||
state persisting indefinitely. The stash defines two operations;
|
||||
`put`, to add state and `take` to remove state. Furthermore, the view
|
||||
of the stash is path-specific; by default a request will only see the
|
||||
|
|
|
@ -107,7 +107,7 @@ Enrollment
|
|||
experimentType
|
||||
The type of preference experiment. Currently this can take
|
||||
values "exp" and "exp-highpop", the latter being for
|
||||
experiments targetting large numbers of users.
|
||||
experiments targeting large numbers of users.
|
||||
|
||||
Unenrollment
|
||||
method
|
||||
|
|
|
@ -122,7 +122,7 @@ sessions. Note that showing a dialog (including a Firefox dialog) will
|
|||
take Firefox out of focus & end the current session.
|
||||
|
||||
An implementation that records a session when Firefox is completely hidden is
|
||||
preferrable (e.g. to avoid the dialog issue above), however, it's more complex
|
||||
preferable (e.g. to avoid the dialog issue above), however, it's more complex
|
||||
to implement and so we chose not to, at least for the initial implementation.
|
||||
|
||||
profileDate
|
||||
|
|
|
@ -645,7 +645,7 @@ See the ``UITelemetry data format`` documentation.
|
|||
|
||||
slowSQL
|
||||
-------
|
||||
This section contains the informations about the slow SQL queries for both the main and other threads. The execution of an SQL statement is considered slow if it takes 50ms or more on the main thread or 100ms or more on other threads. Slow SQL statements will be automatically trimmed to 1000 characters. This limit doesn't include the ellipsis and database name, that are appended at the end of the stored statement.
|
||||
This section contains the information about the slow SQL queries for both the main and other threads. The execution of an SQL statement is considered slow if it takes 50ms or more on the main thread or 100ms or more on other threads. Slow SQL statements will be automatically trimmed to 1000 characters. This limit doesn't include the ellipsis and database name, that are appended at the end of the stored statement.
|
||||
|
||||
Structure:
|
||||
|
||||
|
|
|
@ -122,7 +122,7 @@ These values should be monotonic. If we can't get a monotonic timestamp, -1 will
|
|||
uid
|
||||
~~~~~~~~~
|
||||
|
||||
This property containing a hash of the FxA account identifier, which is a 32 character hexidecimal string. In the case that we are unable to authenticate with FxA and have never authenticated in the past, it will be a placeholder string consisting of 32 repeated ``0`` characters.
|
||||
This property containing a hash of the FxA account identifier, which is a 32 character hexadecimal string. In the case that we are unable to authenticate with FxA and have never authenticated in the past, it will be a placeholder string consisting of 32 repeated ``0`` characters.
|
||||
|
||||
syncs.why
|
||||
~~~~~~~~~
|
||||
|
|
|
@ -749,7 +749,7 @@ plugin
|
|||
theme
|
||||
Integer count of installed themes.
|
||||
lwtheme
|
||||
Integer count of installed lightweigh themes.
|
||||
Integer count of installed lightweight themes.
|
||||
|
||||
Notes
|
||||
^^^^^
|
||||
|
|
Загрузка…
Ссылка в новой задаче