The eyedropper code now bails out if the content window is XUL, since
highlighters cant be inserted into non-HTML documents.
And the inspector hides the eyedropper buttons in the toolbar and in the
color-picker if the document isn't HTML.
MozReview-Commit-ID: 7AgRV8Qu9gz
--HG--
extra : rebase_source : 04220a6057df9ced4b49c29e8b46557008e0d738
This switches getPrompt to use a ChromeWindow which matches what the shipping code does for e10s.
MozReview-Commit-ID: DcVSr6JfmdK
--HG--
extra : rebase_source : 35178483a1223c71c0dd2142479799225ccde1bb
Bug 1058438 moved disabled hosts to the permission manager which are already cleared by these modules.
MozReview-Commit-ID: InprrYLvjMR
--HG--
extra : rebase_source : 806c2542cbab953b74ad82611501ecac32400930
This introduces a new NLP (Natural Language Processing) module with only one
method: 'levenstein'. We're using it to allow the highlighter to keep running
when the it starts the iterator with a word that's one edit distance behind the
value in the findField.
MozReview-Commit-ID: K8oeiXoiLUe
The spec recently changed to match browsers better. There's currently
not much interop in exact details of how this work. This brings us in
line with the spec except for the limit of 1000 on the span attribute.
The added textarea failures are spurious, because I'm not updating our
local tests in this commit. The new tests are submitted upstream at
<https://github.com/w3c/web-platform-tests/pull/3518>.
MozReview-Commit-ID: 1L8aUtF47Qi
This fix is not related to the referenced bug but came up during review.
MozReview-Commit-ID: IjrxWzkLIq1
--HG--
extra : rebase_source : d53179af98106049bcf1a12efed74c4527ac62c1
And change `this.global.Object.create(null)` to
`Cu.createObjectIn(this.global)`. The tests pass either way, but
`Cu.createObjectIn` is more explicit.
MozReview-Commit-ID: LmL6rTru5zZ
--HG--
extra : rebase_source : 4cf7b1463bf8b6882b6fd453657eae0ff43ed64d
Split the `shouldInject` method into separate methods:
- `shouldInject` to determine whether the API (or namespace)
should be injected.
- `getImplementation` to return the actual implementation.
Introduced `SchemaAPIInterface` for documentation purposes, and
two concrete implementations `LocalAPIImplementation` and
`ProxyAPIImplementation` which provide the functionality to run a local
and remote implementation of the API for which the schema API is
generated, respectively. These classes store the necessary details for
the invocation, so the methods that were formerly in the `Context` in
Schemas.jsm no longer get the `pathObj`, `path` or `name` parameters.
And merge the `path` and `name` in the implementation of remote APIs
because there is no need for having them separate, as the callers and
callees often did redundant pre/post-processing on `data.path` because
of the way it was implemented.
MozReview-Commit-ID: isbG9i9pNP
--HG--
extra : rebase_source : 22cdc3ab3d14c6381f9f540739d6750281ae8c71
The API implementation is already available upfront when the schema API
is generated, so `pathObj` has the implementation and can be used
instead of looking up the implementation over and over again with
`findPathInObject`.
MozReview-Commit-ID: FnCIyoaxgA4
--HG--
extra : rebase_source : 440b25fcfb4a0438b1ff8680ad770930e7427de7
In test_marionette_runner.py, fix pytest warning raised when
importing TestManifest class directly in global namespace.
In test_marionette_arguments.py, improve readability by
shortening/changing some names and removing unnecessary
comments (not needed as code is self-explanatory).
MozReview-Commit-ID: GDzxlEqb7MB
--HG--
extra : rebase_source : 78927cae7f8ec011d2b398e3a1ce71174d7b028c
Split the Marionette harness unit tests, all of which were
previously located in the single module test_marionette_runner.py,
into modules that each test a specific class or group of
similar classes. This will make it easier to add and locate
new tests in the future, based on the class they are testing.
The new module structure within tests/harness_unit/ is:
* test_marionette_harness.py - tests for MarionetteHarness and
the command-line interface
* test_marionette_arguments.py - tests for MarionetteArguments
(future: BaseMarionetteArguments and RemoteMarionetteArguments)
* test_marionette_runner.py - tests for MarionetteTestRunner
and BaseMarionetteTestRunner (future: MarionetteTextTestRunner)
* test_marionette_test_result.py - tests for MarionetteTestResult
(future: MarionetteTest)
* conftest.py - pytest fixtures used in multiple modules
(fixtures specific to a single module are defined in that module)
MozReview-Commit-ID: CGh6Aa07lfV
--HG--
extra : rebase_source : faa7d27135aa6e4c6c44fa60aab6f2b5d6339961
The assumption was that the waiting event would be fired once the last frame prior the gap had been played. This is however incorrect, as per spec, the waiting event is to be fired once readyState is <= HAVE_CURRENT_DATA. So the waiting event is actually fired anytime between the start of the last frame and its end.
MozReview-Commit-ID: AA4Qhn7okhB
--HG--
extra : rebase_source : fc1f336b2e07cc2549071563804de8fae9c9ab67
Otherwise we get intermittent in mochitests checking the value of currenTime when events are fired
MozReview-Commit-ID: AVktWrXochp
--HG--
extra : rebase_source : 76c952e62e9b449834d5924454c25ddad305ada6
1- We shouldn't reach ended if we have a gap in the buffered range prior the end of the file (see bug 1297036)
2- Waiting should be fired when readyState goes below HAVE_FUTURE_DATA
MozReview-Commit-ID: 18bEnkNpYvO
--HG--
extra : rebase_source : c42c7fd19fec9ede5bb64ea697a0086116882403
The test accidentally worked because any demuxing failures in ended mode would be treated as EOS. There's no audio between [0-3), so playback couldn't start
MozReview-Commit-ID: 4B90CrVUTy4
--HG--
extra : rebase_source : 9079aa8a6983877745baac71c7868ca360b85095
The aim is to only allow skipping gaps of fuzz=500ms.
MozReview-Commit-ID: 8uHxni2nPHI
--HG--
extra : rebase_source : ccef593170fb3a0c3ff61dc97ad1a0508be06934
This reverts commit 5a949eb358e27
Another more complete solution will follow.
MozReview-Commit-ID: K3lTdrBxW7W
--HG--
extra : rebase_source : d0f9443193b0816ae85972a4a368599b872fd437
Seeking in the buffered range should always succeed, even if we have no data in a given track
MozReview-Commit-ID: FGjsDCNIdWC
--HG--
extra : rebase_source : c91348e44055f82deee0e97da4abef0cf799b225
Shih-Chiang Chien
tlin@mozilla.com
Phil Ringnalda
Chris H-C
Patrick Brosset
Michael Li
rsx11m
Matthew Noorenberghe
Wes Kocher
Mike de Boer
Aryeh Gregor
Rob Wu
Emanuel Hoogeveen
Mark Hammond
Sebastian Hengst
Jan-Ivar Bruaroey
Anjana Vakil
Jean-Yves Avenard