mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-08 02:14:43 +00:00
Bug 1598971 - codespell: Fix typos in the doc r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,ato
Depends on D54430 Differential Revision: https://phabricator.services.mozilla.com/D54431 --HG-- extra : moz-landing-system : lando
This commit is contained in:
parent
df4066dd02
commit
ba488cdc09
@ -1,7 +1,7 @@
|
||||
# How to run experiments with ASRouter
|
||||
|
||||
This guide will tell you how to run an experiment with ASRouter messages.
|
||||
Note that the actual experiment proccess and infrastructure is handled by
|
||||
Note that the actual experiment process and infrastructure is handled by
|
||||
the experiments team (#ask-experimenter).
|
||||
|
||||
## Why run an experiment
|
||||
|
@ -15,7 +15,7 @@ switch out as the user switches contexts. The same naming convention is used in
|
||||
this document.
|
||||
|
||||
In this document and in the code, the word "input" is used to refer to
|
||||
an interactive element in the Touch Bar. It is often interchangable with
|
||||
an interactive element in the Touch Bar. It is often interchangeable with
|
||||
"button", but "input" can also refer to any element displayed in the Touch Bar.
|
||||
|
||||
The Touch Bar should never offer functionality unavailable to Firefox users
|
||||
|
@ -357,7 +357,7 @@ Add-on experiments
|
||||
Mozilla extensions.
|
||||
|
||||
An add-on experiment can collect additional telemetry that's not collected in
|
||||
the product by using the priveleged ``browser.telemetry`` WebExtensions API,
|
||||
the product by using the privileged ``browser.telemetry`` WebExtensions API,
|
||||
and of course the product will continue to collect all the telemetry it
|
||||
usually does. The telemetry pings from users running the experiment will be
|
||||
correlated with the experiment with no extra work on our part.
|
||||
|
@ -289,7 +289,7 @@ For instance, if we have the following HTML markup and we have to choose a class
|
||||
|
||||
Sometimes we have a component that should change its style depending on its state, or we have some rules that allow us to customize further how something looks. For instance, we could have a generic rule for buttons, and then some extra rules for primary buttons, or for tiny ones.
|
||||
|
||||
In BEM, style variants are created with a double hypen `--`. For example:
|
||||
In BEM, style variants are created with a double hyphen `--`. For example:
|
||||
|
||||
```css
|
||||
.ui-button { /* styles for buttons */ }
|
||||
|
@ -154,7 +154,7 @@ While decently effective, there are currently two downsides to this approach:
|
||||
|
||||
* The "live" behavior of imports is often implemented using accessor
|
||||
properties, which as of the time of this writing, cannot be evaluated to
|
||||
retreive their real value.
|
||||
retrieve their real value.
|
||||
* The "live" behavior of imports is sometimes implemented with function calls,
|
||||
which also also cannot be evaluated, causing their value to be
|
||||
unknown.
|
||||
|
@ -355,7 +355,7 @@ How to start porting parent-process browser code to use JSWindowActors
|
||||
|
||||
The :ref:`fission.message-manager-actors` work made it much easier to migrate away from framescripts towards something that is similar to ``JSWindowActors``. It did not, however, substantially change how the parent process interacted with those framescripts.
|
||||
|
||||
So when porting code to work with ``JSWindowActors``, we find that this is often where the time goes - refactoring the parent process browser code to accomodate the new ``JSWindowActor`` model.
|
||||
So when porting code to work with ``JSWindowActors``, we find that this is often where the time goes - refactoring the parent process browser code to accommodate the new ``JSWindowActor`` model.
|
||||
|
||||
Usually, the first thing to do is to find a reasonable name for your actor pair, and get them registered (see :ref:`fission.registering-a-new-jswindowactor`), even if the actors implementations themselves are nothing but unmodified subclasses of ``JSWindowActorParent`` and ``JSWindowActorChild``.
|
||||
|
||||
|
@ -126,10 +126,10 @@ Rationale
|
||||
Optimally, test names should be structured hierarchically to allow
|
||||
easy selection of groups of tests for execution. However, gtest has some
|
||||
restrictions that do not allow that completely. The guidelines try to
|
||||
accomodate for these as far as possible. Note that gtest recommends not to
|
||||
accommodate for these as far as possible. Note that gtest recommends not to
|
||||
use underscores in test names in general, because this may lead to reserved
|
||||
names and naming conflicts, but the rules stated here should avoid that.
|
||||
In case of any problems arising, we can evolve the rules to accomodate
|
||||
In case of any problems arising, we can evolve the rules to accommodate
|
||||
for that.
|
||||
|
||||
Specifying types
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Description
|
||||
|
||||
This project includes Win32 headers for communicating to Windows Hello and external secruity keys as part of WebAuthN and CTAP specification.
|
||||
This project includes Win32 headers for communicating to Windows Hello and external security keys as part of WebAuthN and CTAP specification.
|
||||
|
||||
For more details about the standards, please follow these links:
|
||||
* WebAuthN: https://w3c.github.io/webauthn/
|
||||
|
@ -2,7 +2,7 @@ A parser generator used to generate the following files:
|
||||
|
||||
- js/src/frontend/BinASTParser.h
|
||||
- js/src/frontend/BinASTParser.cpp
|
||||
- js/src/frontent/BinASTToken.h
|
||||
- js/src/frontend/BinASTToken.h
|
||||
|
||||
from the following files:
|
||||
|
||||
|
@ -48,7 +48,7 @@ To do that this component glue together three main high level components:
|
||||
Connecting to Websocket endpoints
|
||||
---------------------------------
|
||||
|
||||
Each target's websocket URL will be registered as a HTTP enpoint via `server/HTTPD:registerPathHandler`.
|
||||
Each target's websocket URL will be registered as a HTTP endpoint via `server/HTTPD:registerPathHandler`.
|
||||
(This registration is done from `RemoteAgent:init`)
|
||||
Once a HTTP request happens, `server/HTTPD` will call the `handle` method on the object passed to `registerPathHandler`.
|
||||
For static endpoints registered by `JSONHandler`, this will call `JSONHandler:handle` and return a JSON string as http body.
|
||||
@ -107,7 +107,7 @@ In both cases, `Target.attachToTarget()` is special as it will spawn `session/Ta
|
||||
This is the codepath creating non-default session. The default session is related to the target you originally connected to,
|
||||
so that you don't need any ID for this one. When you want to debug more than one target over a single connection
|
||||
you need additional sessions, which will have a unique ID.
|
||||
`Target.attachToTarget` will compute this ID and instanciate a new session bound to the given target.
|
||||
`Target.attachToTarget` will compute this ID and instantiate a new session bound to the given target.
|
||||
This additional session will be managed by the `Connection` class, which will then redirect CDP packets to the
|
||||
right session when you are using flatten session.
|
||||
|
||||
|
@ -87,7 +87,7 @@ It shares the same security model as DevTools and Marionette, in
|
||||
that there is no other mechanism for enabling the remote agent than
|
||||
by passing a command-line flag.
|
||||
|
||||
It is our assumption that if an attacker has shell acccess to the
|
||||
It is our assumption that if an attacker has shell access to the
|
||||
user account, there is little we can do to prevent secrets from
|
||||
being accessed or leaked.
|
||||
|
||||
|
@ -317,7 +317,7 @@ For example, the local data of the ``"key"`` collection can be accessed in the `
|
||||
Unit Tests
|
||||
==========
|
||||
|
||||
As a foreword, we would like to underline the fact that your tests should not test Remote Settings itself. Your tests should assume Remote Settings works, and should only run assertions on the integration part. For example, if you see yourself mocking the server responses, your tests may go over their responsability.
|
||||
As a foreword, we would like to underline the fact that your tests should not test Remote Settings itself. Your tests should assume Remote Settings works, and should only run assertions on the integration part. For example, if you see yourself mocking the server responses, your tests may go over their responsibility.
|
||||
|
||||
If your code relies on the ``"sync"`` event, you are likely to be interested in faking this event and make sure your code runs as expected. If it relies on ``.get()``, you will probably want to insert some fake local data.
|
||||
|
||||
|
@ -179,7 +179,7 @@ with this particular release that we intend to release a fix for soon.
|
||||
|
||||
- Introduces `strictFileInteractability` capability
|
||||
|
||||
The new capabilitiy indicates if strict interactability checks
|
||||
The new capability indicates if strict interactability checks
|
||||
should be applied to `<input type=file>` elements. As strict
|
||||
interactability checks are off by default, there is a change
|
||||
in behaviour when using [Element Send Keys] with hidden file
|
||||
@ -731,7 +731,7 @@ and greater.
|
||||
|
||||
- Disable Flash and the plugin container in Firefox by
|
||||
default, which should help mitigate the “Plugin Container
|
||||
for Firefox has stopped wroking” problems [many users were
|
||||
for Firefox has stopped working” problems [many users were
|
||||
reporting](https://github.com/mozilla/geckodriver/issues/225) when
|
||||
deleting a session
|
||||
|
||||
@ -740,7 +740,7 @@ and greater.
|
||||
[Marc Fisher](https://github.com/DrMarcII))
|
||||
- The exceptions are the `marionette.port` and `marionette.log.level`
|
||||
preferences and their fallbacks, which are set unconditionally and
|
||||
cannot be overriden
|
||||
cannot be overridden
|
||||
|
||||
- Remove default preference that disables unsafe CPOW checks
|
||||
|
||||
@ -749,7 +749,7 @@ and greater.
|
||||
### Fixed
|
||||
|
||||
- Fix for the “corrupt deflate stream” exception that
|
||||
sometimes occured when trying to write an empty profile by
|
||||
sometimes occurred when trying to write an empty profile by
|
||||
[@kirhgoph](https://github.com/kirhgoph)
|
||||
|
||||
- Recognise `sslProxy` and `sslProxyPort` entries in the proxy
|
||||
@ -793,7 +793,7 @@ and greater.
|
||||
- Now uses about:blank as the new tab document; this was previously
|
||||
disabled due to [bug 1333736](https://bugzil.la/1333736) in Marionette
|
||||
|
||||
- WebDriver libary updated to 0.23.0
|
||||
- WebDriver library updated to 0.23.0
|
||||
|
||||
### Fixed
|
||||
|
||||
@ -902,7 +902,7 @@ and greater.
|
||||
|
||||
### Added
|
||||
|
||||
- Introduced continous integration builds for Linux- and Windows 32-bit
|
||||
- Introduced continuous integration builds for Linux- and Windows 32-bit
|
||||
binaries
|
||||
|
||||
- Added commands for setting- and getting the window position
|
||||
@ -1200,7 +1200,7 @@ and greater.
|
||||
- Make failing to communicate with Firefox a fatal error that closes
|
||||
the session
|
||||
|
||||
- Shut down session only when loosing connection
|
||||
- Shut down session only when losing connection
|
||||
|
||||
- Better handling of missing command line flags
|
||||
|
||||
|
@ -17,7 +17,7 @@ cross-compile ARMv7 from a Linux host system is as follows:
|
||||
|
||||
# apt install gcc-arm-linux-gnueabihf libc6-armhf-cross libc6-dev-armhf-cross
|
||||
|
||||
3. Createa a new shell, or to reuse the existing shell:
|
||||
3. Create a new shell, or to reuse the existing shell:
|
||||
|
||||
source $HOME/.cargo/env
|
||||
|
||||
|
@ -36,7 +36,7 @@ central by using relative paths:
|
||||
Because we need to export the geckodriver source code to the old
|
||||
GitHub repository when we release, we first need to publish these
|
||||
crates if they have had any changes in the interim since the last
|
||||
release. If they have receieved no changes, you can skip them:
|
||||
release. If they have received no changes, you can skip them:
|
||||
|
||||
- `testing/mozbase/rust/mozprofile`
|
||||
- `testing/mozbase/rust/mozrunner`
|
||||
@ -69,7 +69,7 @@ is implemented there.
|
||||
|
||||
We follow the writing style of the existing change log, with
|
||||
one section per version (with a release date), with subsections
|
||||
‘Added’, ‘Changed’, and ‘Removed’. If the targetted
|
||||
‘Added’, ‘Changed’, and ‘Removed’. If the targeted
|
||||
Firefox or Selenium versions have changed, it is good to make a
|
||||
mention of this. Lines are optimally formatted at roughly 72 columns
|
||||
to make the file readable in a text editor as well as rendered HTML.
|
||||
@ -102,7 +102,7 @@ Bump the version number and update the support page
|
||||
|
||||
Bump the version number in [Cargo.toml] to the next version.
|
||||
geckodriver follows [semantic versioning] so it’s a good idea to
|
||||
familiarise yourself wih that before deciding on the version number.
|
||||
familiarise yourself with that before deciding on the version number.
|
||||
|
||||
After you’ve changed the version number, run
|
||||
|
||||
|
@ -120,7 +120,7 @@ supported release from Mozilla.
|
||||
|
||||
To run tests on Android specific capabilities under `moz:firefoxOptions`
|
||||
have to be set when requesting a new session. See the Android section under
|
||||
[Firefox Capabilties](Capabilities.html#android) for more details.
|
||||
[Firefox Capabilities](Capabilities.html#android) for more details.
|
||||
|
||||
[geckodriver releases]: https://github.com/mozilla/geckodriver/releases
|
||||
[Selenium]: https://github.com/seleniumhq/selenium
|
||||
|
@ -25,7 +25,7 @@ make sure you have built Firefox:
|
||||
% ./mach wpt testing/web-platform/tests/webdriver
|
||||
|
||||
As these are functional integration tests and pop up Firefox windows
|
||||
sporadically, a helpful tip is to surpress the window whilst you
|
||||
sporadically, a helpful tip is to suppress the window whilst you
|
||||
are running them by using Firefox’ [headless mode]:
|
||||
|
||||
% ./mach wpt --headless testing/web-platform/tests/webdriver
|
||||
|
@ -32,7 +32,7 @@ Or by passing it as a flag to the [java(1)] launcher:
|
||||
|
||||
% java -Dwebdriver.gecko.driver=/home/user/bin YourApplication
|
||||
|
||||
Your milage with this approach may vary based on which programming
|
||||
Your mileage with this approach may vary based on which programming
|
||||
language bindings you are using. It is in any case generally the case
|
||||
that geckodriver will be picked up if it is available on the system path.
|
||||
In a bash compatible shell, you can make other programs aware of its
|
||||
|
@ -61,7 +61,7 @@ Work on bugs and get code review
|
||||
|
||||
Once you are familiar with the code of the test harnesses, and the tests you might
|
||||
want to start with your first contribution. The necessary steps to submit and verify
|
||||
your patches are layed out in [Patches.md](Patches.html).
|
||||
your patches are laid out in [Patches.md](Patches.html).
|
||||
|
||||
|
||||
Resources
|
||||
|
@ -30,12 +30,12 @@ Schematic flow of messages:
|
||||
|
||||
The protocol consists of a [command] message and the corresponding
|
||||
[response] message. A [response] message must always be sent in
|
||||
reply to a [commmand] message.
|
||||
reply to a [command] message.
|
||||
|
||||
This means that the server implementation does not need to send
|
||||
the reply precisely in the order of the received commands: if it
|
||||
receives multiple messages, the server may even reply in random order.
|
||||
It is therefore strongly adviced that clients take this into account
|
||||
It is therefore strongly advised that clients take this into account
|
||||
when imlpementing the client end of this wire protocol.
|
||||
|
||||
This is required for pipelining messages. On the server side,
|
||||
|
@ -3,7 +3,7 @@ Selenium atoms
|
||||
|
||||
Marionette uses a small list of [Selenium atoms] to interact with
|
||||
web elements. Initially those have been added to ensure a better
|
||||
reliablity due to a wider usage inside the Selenium project. But
|
||||
reliability due to a wider usage inside the Selenium project. But
|
||||
by adding full support for the [WebDriver specification] they will
|
||||
be removed step by step.
|
||||
|
||||
@ -62,7 +62,7 @@ code including dependencies for the atom wrapped into a single function.
|
||||
### Update atom.js
|
||||
|
||||
To update the atoms for Marionette the `atoms.js` file has to be edited. For
|
||||
each atom to be updated the steps as layed out below have to be performed:
|
||||
each atom to be updated the steps as laid out below have to be performed:
|
||||
|
||||
1. Open the Javascript file of the exported atom. See above for
|
||||
its location.
|
||||
|
@ -165,7 +165,7 @@ Release History
|
||||
13.0.0 (2015-05-21)
|
||||
-------------------
|
||||
|
||||
* Automatically install wheel when creating a new virutalenv. This can be
|
||||
* Automatically install wheel when creating a new virtualenv. This can be
|
||||
disabled by using the ``--no-wheel`` option.
|
||||
|
||||
* Don't trust the current directory as a location to discover files to install
|
||||
|
@ -80,7 +80,7 @@ below.
|
||||
|
||||
If using Powershell, the ``activate`` script is subject to the
|
||||
`execution policies`_ on the system. By default on Windows 7, the system's
|
||||
excution policy is set to ``Restricted``, meaning no scripts like the
|
||||
execution policy is set to ``Restricted``, meaning no scripts like the
|
||||
``activate`` script are allowed to be executed. But that can't stop us
|
||||
from changing that slightly to allow it to be executed.
|
||||
|
||||
|
@ -263,7 +263,7 @@ that are only set on nightly), for example:
|
||||
if release_or_beta: FAIL
|
||||
|
||||
Note that in general the automatic metadata update will work better if
|
||||
the nonstandard configuration is used explictly in the conditional,
|
||||
the nonstandard configuration is used explicitly in the conditional,
|
||||
and placed at the top of the set of conditions, i.e. the following
|
||||
would cause problems later:
|
||||
|
||||
|
@ -1102,7 +1102,7 @@ a {
|
||||
|
||||
Debug:</pre></div>
|
||||
<div class="backtrace"><pre>./annotation-vocab_spec.rb:83:in `block (4 levels) in <top (required)>'</pre></div>
|
||||
<pre class="ruby"><code><span class="linenum">81</span> # XXX Normalize whitespace in literals to ease comparision
|
||||
<pre class="ruby"><code><span class="linenum">81</span> # XXX Normalize whitespace in literals to ease comparison
|
||||
<span class="linenum">82</span> fg.each_object {|o| o.squish! if o.literal?}
|
||||
<span class="offending"><span class="linenum">83</span> expect(fg).to be_equivalent_graph(vocab_graph)</span>
|
||||
<span class="linenum">84</span> end
|
||||
@ -2073,7 +2073,7 @@ a {
|
||||
|
||||
Debug:</pre></div>
|
||||
<div class="backtrace"><pre>./annotation-vocab_spec.rb:83:in `block (4 levels) in <top (required)>'</pre></div>
|
||||
<pre class="ruby"><code><span class="linenum">81</span> # XXX Normalize whitespace in literals to ease comparision
|
||||
<pre class="ruby"><code><span class="linenum">81</span> # XXX Normalize whitespace in literals to ease comparison
|
||||
<span class="linenum">82</span> fg.each_object {|o| o.squish! if o.literal?}
|
||||
<span class="offending"><span class="linenum">83</span> expect(fg).to be_equivalent_graph(vocab_graph)</span>
|
||||
<span class="linenum">84</span> end
|
||||
|
@ -33,7 +33,7 @@ Using `support/property.js` test suites compile a list of animatable properties.
|
||||
}
|
||||
```
|
||||
|
||||
For each compiled test case the test runner identifies computed initial and target values. If they match, no transition will take place, because the property couldn't be parsed. If after starting the transition the computed style matches the target value, the browser applied that value immedately and no transition will take place. During the transition the computed style may match neither initial nor target value (unless it's a discrete transition), or there was no transition.
|
||||
For each compiled test case the test runner identifies computed initial and target values. If they match, no transition will take place, because the property couldn't be parsed. If after starting the transition the computed style matches the target value, the browser applied that value immediately and no transition will take place. During the transition the computed style may match neither initial nor target value (unless it's a discrete transition), or there was no transition.
|
||||
|
||||
Besides value-assertions, the suites compare received TransitionEnd events. While the values are only matched against computed initial and target values, expected TransitionEnd events are declared explicitly. This can (and will) lead to some test failures that are arguably not a failure (mainly because the specification didn't cover the specific case). Transitioning `color` *may* (or not, depending on browser) also run a transition for `background-color`, as the latter's default value is `currentColor`. This suite considers those implicit transitions a failure. If it truly is a failure or not, should be decided in the specification (and tests updated accordingly).
|
||||
|
||||
|
@ -3,7 +3,7 @@ apiclient
|
||||
|
||||
Client class for calling http+json APIs in Python. Requires Python 2.7.
|
||||
|
||||
Suports json home pages per:
|
||||
Supports json home pages per:
|
||||
http://tools.ietf.org/html/draft-nottingham-json-home-03
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ Get a named APIResource.
|
||||
|
||||
**APIClient.setVersion(name, version)**
|
||||
|
||||
Set the request version identifier for a specific resource. If not set, the default version identifer will be used.
|
||||
Set the request version identifier for a specific resource. If not set, the default version identifier will be used.
|
||||
|
||||
**APIClient.setAccept(name, mimeType)**
|
||||
|
||||
|
@ -92,8 +92,8 @@ The main thing here is the `postMessage` argument. The first argument is an obje
|
||||
- `action`: the name of the testdriver command this defines (in this case, `set_window_rect`)
|
||||
- any other things you want to pass to the next point of execution (in this case, the x, y coordinates and the width and height)
|
||||
|
||||
<!-- The pending promise needs to be there as it is resolved when the window recieves a completion message from the executor. -->
|
||||
The pending promise is out of scope of this function and is resolved when the window recieves a completion message from the executor.
|
||||
<!-- The pending promise needs to be there as it is resolved when the window receives a completion message from the executor. -->
|
||||
The pending promise is out of scope of this function and is resolved when the window receives a completion message from the executor.
|
||||
This happens here in the same file:
|
||||
|
||||
```javascript
|
||||
|
@ -101,7 +101,7 @@ Usage: `test_driver.click(element)`
|
||||
This function causes a click to occur on the target element (an
|
||||
`Element` object), potentially scrolling the document to make it
|
||||
possible to click it. It returns a `Promise` that resolves after the
|
||||
click has occured or rejects if the element cannot be clicked (for
|
||||
click has occurred or rejects if the element cannot be clicked (for
|
||||
example, it is obscured by an element on top of it).
|
||||
|
||||
Note that if the element to be clicked does not have a unique ID, the
|
||||
|
@ -3,7 +3,7 @@ dpub-aam: Tests for the DPUB-ARIA Accessibility Mapping Recommendation
|
||||
|
||||
The [DPUB ARIA Recommendation](https://www.w3.org/TR/dpub-aam-1.0)
|
||||
define extensions to HTML4/5 for support of extended semantics. These
|
||||
semantics make it easier for Assistive Technologies to intepret and
|
||||
semantics make it easier for Assistive Technologies to interpret and
|
||||
present content to users with varying physical and cognitive abilities.
|
||||
|
||||
The purpose of these tests is to help ensure that user agents support the
|
||||
|
@ -3,7 +3,7 @@ dpub-aria: Tests for the DPUB-ARIA Recommendations
|
||||
|
||||
The [DPUB ARIA Recommendation](https://www.w3.org/TR/dpub-aria-1.0)
|
||||
define extensions to HTML4/5 for support of extended semantics. These
|
||||
semantics make it easier for Assistive Technologies to intepret and
|
||||
semantics make it easier for Assistive Technologies to interpret and
|
||||
present content to users with varying physical and cognitive abilities.
|
||||
|
||||
The purpose of these tests is to help ensure that user agents support the
|
||||
|
@ -4,7 +4,7 @@ An array of tests. Each test has these fields:
|
||||
|
||||
* `contentType`: an array of values for the `Content-Type` header. A harness needs to run the test twice if there are multiple values. One time with the values concatenated with `,` followed by a space and one time with multiple `Content-Type` declarations, each on their own line with one of the values, in order.
|
||||
* `encoding`: the expected encoding, null for the default.
|
||||
* `mimeType`: the result of extracing a MIME type and serializing it.
|
||||
* `mimeType`: the result of extracting a MIME type and serializing it.
|
||||
* `documentContentType`: the MIME type expected to be exposed in DOM documents.
|
||||
|
||||
(These tests are currently somewhat geared towards browser use, but could be generalized easily enough if someone wanted to contribute tests for MIME types that would cause downloads in the browser or some such.)
|
||||
|
@ -3,7 +3,7 @@ svg-aam: Tests for the SVG Accessibility API Mappings
|
||||
|
||||
The [SVG AAM Recommendation](https://www.w3.org/TR/svg-aam-1.0)
|
||||
define extensions to SVG for support of extended semantics. These
|
||||
semantics make it easier for Assistive Technologies to intepret and
|
||||
semantics make it easier for Assistive Technologies to interpret and
|
||||
present content to users with varying physical and cognitive abilities.
|
||||
|
||||
The purpose of these tests is to help ensure that user agents support the
|
||||
|
@ -248,7 +248,7 @@ When used for expectation data, manifests have the following format:
|
||||
base test URL, in which case the fuzziness applies to any
|
||||
comparison with that URL, or takes the form lhs url, comparison,
|
||||
rhs url, in which case the fuzziness only applies for any
|
||||
comparison involving that specifc pair of URLs. Some illustrative
|
||||
comparison involving that specific pair of URLs. Some illustrative
|
||||
examples are given below.
|
||||
|
||||
* Variables ``debug``, ``os``, ``version``, ``processor`` and
|
||||
|
@ -3,7 +3,7 @@ Wai-aria: Tests for the WAI-ARIA Recommendations
|
||||
|
||||
The [WAI ARIA Recommendations](https://www.w3.org/TR/wai-aria)
|
||||
define extensions to HTML4/5 for support of extended semantics. These
|
||||
semantics make it easier for Assistive Technologies to intepret and
|
||||
semantics make it easier for Assistive Technologies to interpret and
|
||||
present content to users with varying physical and cognitive abilities.
|
||||
|
||||
The purpose of these tests is to help ensure that user agents support the
|
||||
|
@ -225,7 +225,7 @@ Version history
|
||||
### 0.0.6 (2013-07-19) ###
|
||||
|
||||
* `Connection` and `Endpoint` classes are usable, but not yet ready
|
||||
* Addition of an exmaple server and client
|
||||
* Addition of an example server and client
|
||||
* Using [istanbul](https://github.com/gotwarlost/istanbul) for measuring code coverage
|
||||
* [Blog post](http://gabor.molnar.es/blog/2013/07/19/gsoc-week-number-5/)
|
||||
* [Tarball](https://github.com/molnarg/node-http2/archive/node-http2-0.0.6.tar.gz)
|
||||
|
@ -116,9 +116,9 @@ Example
|
||||
|
||||
Firefox Content Blocking blocks web content from certain origins present on a list.
|
||||
Users can exempt certain origins from being blocked.
|
||||
To improve Content Blocking's effectiveness we need to know these two "whats" of information about that list of "wheres".
|
||||
To improve Content Blocking's effectiveness we need to know these two "what's" of information about that list of "wheres".
|
||||
|
||||
This means we need two metrics ``contentblocking.blocked`` and ``contentblocking.exempt`` (the "whats"), and a list of origins (the "wheres").
|
||||
This means we need two metrics ``contentblocking.blocked`` and ``contentblocking.exempt`` (the "what's"), and a list of origins (the "wheres").
|
||||
|
||||
Say "example.net" was blocked and "example.com" was exempted from blocking.
|
||||
Content Blocking calls ``Telemetry::RecordOrigin(OriginMetricID::ContentBlocking_Blocked, NS_LITERAL_CSTRING("example.net"))`` and ``Telemetry::RecordOrigin(OriginMetricID::ContentBlocking_Exempt, NS_LITERAL_CSTRING("example.com"))``.
|
||||
|
@ -47,7 +47,7 @@ List of phases
|
||||
|
||||
``FirstStartup.NOT_STARTED``
|
||||
|
||||
The ``FirstStartup`` module has not been initalized (the ``init()``
|
||||
The ``FirstStartup`` module has not been initialized (the ``init()``
|
||||
function has not been called). This is the default state.
|
||||
|
||||
``FirstStartup.IN_PROGRESS``
|
||||
|
Loading…
Reference in New Issue
Block a user