Bug 1496026 - Fix some trivial typos r=ahal
authorSylvestre Ledru <sledru@mozilla.com>
Wed, 03 Oct 2018 13:39:07 +0000
changeset 495125 853e6a2f456157b664591ba47f30d8a3482b1bf8
parent 495095 6bca826c27cf5f951069fe64617dc1e1e58a82ab
child 495126 fde09c00acd82c394072742d1ac36dc829903415
push id9984
push userffxbld-merge
push dateMon, 15 Oct 2018 21:07:35 +0000
treeherdermozilla-beta@183d27ea8570 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1496026 - Fix some trivial typos r=ahal Differential Revision: https://phabricator.services.mozilla.com/D7584
--- a/gfx/docs/AsyncPanZoom.rst
+++ b/gfx/docs/AsyncPanZoom.rst
@@ -233,17 +233,17 @@ Content independently adjusting scrollin
 As described above, there are two copies of the scroll position in the
 APZ architecture - one on the main thread and one on the compositor
 thread. Usually for architectures like this, there is a single “source
 of truth” value and the other value is simply a copy. However, in this
 case that is not easily possible to do. The reason is that both of these
 values can be legitimately modified. On the compositor side, the input
 events the user is triggering modify the scroll position, which is then
 propagated to the main thread. However, on the main thread, web content
-might be running Javascript code that programatically sets the scroll
+might be running Javascript code that programmatically sets the scroll
 position (via window.scrollTo, for example). Scroll changes driven from
 the main thread are just as legitimate and need to be propagated to the
 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
--- a/gfx/docs/Silk.rst
+++ b/gfx/docs/Silk.rst
@@ -26,17 +26,17 @@ 4. The ``CompositorVsyncDispatcher`` not
    ``CompositorWidgetVsyncObserver`` when remote compositing, or a
    ``CompositorVsyncScheduler::Observer`` when compositing in-process.
 5. If remote compositing, a vsync notification is sent from the
    ``CompositorWidgetVsyncObserver`` to the ``VsyncBridgeChild`` on the
    UI process, which sends an IPDL message to the ``VsyncBridgeParent``
    on the compositor thread of the GPU process, which then dispatches to
 6. The ``RefreshTimerVsyncDispatcher`` notifies the Chrome
-   ``RefreshTimer`` that a vsync has occured.
+   ``RefreshTimer`` that a vsync has occurred.
 7. The ``RefreshTimerVsyncDispatcher`` sends IPC messages to all content
    processes to tick their respective active ``RefreshTimer``.
 8. The ``Compositor`` dispatches input events on the *Compositor
    Thread*, then composites. Input events are only dispatched on the
    *Compositor Thread* on b2g.
 9. The ``RefreshDriver`` paints on the *Main Thread*.
 Hardware Vsync
@@ -49,29 +49,29 @@ connected, two ``Display`` objects will 
 vsync events for their respective displays. We require one ``Display``
 object per monitor as each monitor may have different vsync rates. As a
 fallback solution, we have one global ``Display`` object that can
 synchronize across all connected displays. The global ``Display`` is
 useful if a window is positioned halfway between the two monitors. Each
 platform will have to implement a specific ``Display`` object to hook
 and listen to vsync events. As of this writing, both Firefox OS and OS X
 create their own hardware specific *Hardware Vsync Thread* that executes
-after a vsync has occured. OS X creates one *Hardware Vsync Thread* per
+after a vsync has occurred. OS X creates one *Hardware Vsync Thread* per
 ``CVDisplayLinkRef``. We do not currently support multiple displays, so
 we use one global ``CVDisplayLinkRef`` that works across all active
 displays. On Windows, we have to create a new platform ``thread`` that
 waits for DwmFlush(), which works across all active displays. Once the
 thread wakes up from DwmFlush(), the actual vsync timestamp is retrieved
 from DwmGetCompositionTimingInfo(), which is the timestamp that is
 actually passed into the compositor and refresh driver.
 When a vsync occurs on a ``Display``, the *Hardware Vsync Thread*
 callback fetches all ``CompositorVsyncDispatchers`` associated with the
 ``Display``. Each ``CompositorVsyncDispatcher`` is notified that a vsync
-has occured with the vsync’s timestamp. It is the responsibility of the
+has occurred with the vsync’s timestamp. It is the responsibility of the
 ``CompositorVsyncDispatcher`` to notify the ``Compositor`` that is
 awaiting vsync notifications. The ``Display`` will then notify the
 associated ``RefreshTimerVsyncDispatcher``, which should notify all
 active ``RefreshDrivers`` to tick.
 All ``Display`` objects are encapsulated in a ``VsyncSource`` object.
 The ``VsyncSource`` object lives in ``gfxPlatform`` and is instantiated
 only on the parent process when ``gfxPlatform`` is created. The
@@ -137,21 +137,21 @@ compositor to dispatch the notification 
 The ``CompositorVsyncDispatcher`` executes on the *Hardware Vsync
 Thread*. It contains references to the ``nsBaseWidget`` it is associated
 with and has a lifetime equal to the ``nsBaseWidget``. The
 ``CompositorVsyncDispatcher`` is responsible for notifying the
-``CompositorBridgeParent`` that a vsync event has occured. There can be
+``CompositorBridgeParent`` that a vsync event has occurred. There can be
 multiple ``CompositorVsyncDispatchers`` per ``Display``, one
 ``CompositorVsyncDispatcher`` per window. The only responsibility of the
 ``CompositorVsyncDispatcher`` is to notify components when a vsync event
-has occured, and to stop listening to vsync when no components require
+has occurred, and to stop listening to vsync when no components require
 vsync events. We require one ``CompositorVsyncDispatcher`` per window so
 that we can handle multiple ``Displays``. When compositing in-process,
 the ``CompositorVsyncDispatcher`` is attached to the CompositorWidget
 for the window. When out-of-process, it is attached to the
 CompositorWidgetDelegate, which forwards observer notifications over
 IPDL. In the latter case, its lifetime is tied to a CompositorSession
 rather than the nsIWidget.
@@ -377,20 +377,20 @@ After ``VsyncParent::ActorDestroy`` is c
 from the ``RefreshTimerVsyncDispatcher``, which holds the last reference
 to the ``VsyncParent``, and the object will be deleted.
 Thus the overall flow during normal execution is:
 1. VsyncSource::Display::RefreshTimerVsyncDispatcher receives a Vsync
    notification from the OS in the parent process.
 2. RefreshTimerVsyncDispatcher notifies
-   VsyncRefreshTimer::RefreshDriverVsyncObserver that a vsync occured on
+   VsyncRefreshTimer::RefreshDriverVsyncObserver that a vsync occurred on
    the parent process on the hardware vsync thread.
 3. RefreshTimerVsyncDispatcher notifies the VsyncParent on the hardware
-   vsync thread that a vsync occured.
+   vsync thread that a vsync occurred.
 4. The VsyncRefreshTimer::RefreshDriverVsyncObserver in the parent
    process posts a task to the main thread that ticks the refresh
 5. VsyncParent posts a task to the PBackground thread to send a vsync
    IPC message to VsyncChild.
 6. VsyncChild receive a vsync notification on the content process on the
    main thread and ticks their respective RefreshDrivers.
--- a/intl/docs/dataintl.rst
+++ b/intl/docs/dataintl.rst
@@ -251,17 +251,17 @@ to format a value.
 allowing the user to get the current best textual representation of the delta.
 .. code-block:: javascript
     let rtf = new Services.intl.RelativeTimeFormat(undefined, {
       style: "long", // "narrow" | "short" | "long" (default)
-      numeric: "auto", // "always" | "auto" (defualt)
+      numeric: "auto", // "always" | "auto" (default)
     let now = Date.now();
     rtf.formatBestUnit(new Date(now - 3 * 1000 * 60)); // "3 minutes ago"
 The option `numeric` has value set to `auto` by default, which means that when possible
 the formatter will use special textual terms like *yesterday*, *last year*, and so on.