Now that the interfaces are all async, we can simply replace all
the sync IO in the Chrome migrator with the equivalent async IO.
Other browsers will be addressed in separate patches.
MozReview-Commit-ID: FyGRRKY57Gm
--HG--
extra : rebase_source : 0228b9b72c7217e3f6e607256cb3828bf5819189
migration.js is a special case where we generally need blocking
calls in order for the wizard to work correctly. Accordingly we
block waiting for the new async interfaces. With automigration
and potential new UIs that are in the works for migration, the
asynchronicity of these interfaces will be more relevant, but
here it's not really important enough to make big changes to the
way the UI is implemented.
MozReview-Commit-ID: LkfwBVfpCJO
--HG--
extra : rebase_source : 1f9f2c7e2fa20b883840e091dbee366a161eaaf7
In order to clean up sync IO within our profile migrators, we
need to have async interfaces for those parts which are currently
doing sync IO. This converts the sync interfaces and adjusts most
of the call sites (migration.js call site changes are addressed
in a separate patch to break it out a bit).
MozReview-Commit-ID: 2Kcrxco4iYr
--HG--
extra : rebase_source : 53d123c435e43622a999a7e849dddbe1919061e0
B2G used to do shared globals in a weird way which required this, but
that is no longer used.
MozReview-Commit-ID: 9NTQS1NCVtu
--HG--
extra : rebase_source : 000e544a4486fc96b8467be6adc0c22833a14eab
It seems as though pre-Firefox 40 we did a proto-experiment about what a world
without 3rd-party cookies would look like. Near as I can tell, we never looked
at the results of this exploration.
We have much better experimentation and data exploration techniques now that
would allow us to do something better than this, easier. So at least there's
that.
MozReview-Commit-ID: KaOyB87YjGA
--HG--
extra : rebase_source : 69a9a80a7e925b34f6a45f1e02108dd8814f9aab
We don't need this workaround anymore now that we are loading menu.css as a UA sheet
MozReview-Commit-ID: 5OcBkQWIiuw
--HG--
extra : rebase_source : 6446018d1f0877ce295b96eb9f4e4cdac360568a
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 372440bdf73290e268d0a5318cb2c16ecfefcd2a
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : source : 91cfd14052f510f2ba105b257a0d5dbdddb86a13
Initial support for CSS variable autocompletion in ruleview.
MozReview-Commit-ID: AlblDmyW4Iq
--HG--
extra : rebase_source : f19ea980e0d6f141ac5f0c766e37b04c92559e05
B2G used to do shared globals in a weird way which required this, but
that is no longer used.
MozReview-Commit-ID: 9NTQS1NCVtu
--HG--
extra : rebase_source : e9160920f965c6e37157e99a021f25662f68ec75
<!-- Please describe your changes on the following line: -->
@jdm @KiChjang @Manishearth Follow up on https://github.com/servo/servo/pull/18676 and https://github.com/servo/servo/pull/19274 to ignore aborted responses in caching.
I also found out the cache shouldn't return any response whose body is still in `ResponseBody::Receiving` mode, because that fails the assertion at https://github.com/servo/servo/blob/master/components/net/fetch/methods.rs#L438(we might want to add a channel as pat of the cached response later on to deal with this case). I only found out now because I needed the response from the server to trickle in so that it could be cached and aborted.
I copied the `http-cache.py` server from the wpt folder, and added a 'trickle' option, which is necessary to actually have a failing test with a cached but aborted request, it's now passing.
I also remove one unused import that slippled through previously.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4307b6e67b0cb35e2afc46ba0b64e7bc5bde1bdf
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4631dd57c5f691119b287f2aa04ee97fedfdf406
B2G used to do shared globals in a weird way which required this, but
that is no longer used.
MozReview-Commit-ID: DKnNYW5XP1N
--HG--
extra : rebase_source : 499dcc0d141daf72320176fa0115073c9ed08686
Added default fall-back when CARGO_HOME is not set.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#19823 (github issue number if applicable).
Source-Repo: https://github.com/servo/servo
Source-Revision: 06aa339a1bf578d90f4c5a88877b579b67f33a56
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3c3f389c420043db190cb94624b2cea9973f52f0
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : f599de01c63b873a95252d6b01128a6f069ff105
extra : intermediate-source : 060290b66b370137cfd3dbbac7c442ef107aaa68
extra : source : be888fa125dc1948fc073ed69aa8116f47e22877
In preferences tests, all calls to waitForEvent function defined in
browser/components/preferences/in-content/tests/head.js has been replaced with
calls to BrowserTestUtils.waitForEvent.
Since we are no longer using the waitForEvent function defined in the
aforementioned head.js file, that definition has been removed.
MozReview-Commit-ID: IrtGJFtWPPj
--HG--
extra : rebase_source : 9d2fbb6194fa9127a9d559d98371dd60503c5e9e
This patch adds basic support for the fuzzing interface in the JS engine on top
of the last patch. This includes all the necessary code except for actual
targets (just an example target skeleton) and also makes sure that the fuzzing
code is packaged for the standalone release.
MozReview-Commit-ID: D6Tyebz3jZS
--HG--
extra : rebase_source : 58e4d85e657347b061de0ed912365f2a955a86e3
This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be
reused in the JS engine. Changes in detail include:
* Various JS_STANDALONE checks to exclude parts that cannot be included in
those builds.
* Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and
FuzzerRunner classes and use them for AFL as well. Previously, AFL was
piggy-backing on gtests which was kind of an ugly solution anyway (besides
that it can't work in JS). Now more code like registry and harness is
shared between the two and they follow almost the same call paths and entry
points. AFL macros in FuzzingInterface have been rewritten accordingly.
This also required name changes in various places. Furthermore, this unifies
the way, the fuzzing target is selected, using the FUZZER environment
variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give
you a deprecation warning because I know some people are using this already
and need time to switch). Previously, AFL target had to be selected using
GTEST_FILTER, so this is also much better now.
* I had to split up FuzzingInterface* such that the STREAM parts are in a
separate set of files FuzzingInterfaceStream* because they use nsStringStream
which is not allowed to be included into the JS engine even in a full browser
build (error: "Using XPCOM strings is limited to code linked into libxul.").
I also had to pull FuzzingInterface.cpp (the RAW part only) into the header
and make it static because otherwise, would have to make not only separate
files but also separate libraries to statically link to the JS engine, which
seemed overkill for a single small function. The streaming equivalent of the
function is still in a cpp file.
* LibFuzzerRegister functions are now unique by appending the module name to
avoid redefinition errors.
MozReview-Commit-ID: 44zWCdglnHr
--HG--
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.cpp => tools/fuzzing/interface/harness/FuzzerRunner.cpp
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.h => tools/fuzzing/interface/harness/FuzzerRunner.h
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerTestHarness.h => tools/fuzzing/interface/harness/FuzzerTestHarness.h
rename : tools/fuzzing/libfuzzer/harness/moz.build => tools/fuzzing/interface/harness/moz.build
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.cpp => tools/fuzzing/registry/FuzzerRegistry.cpp
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.h => tools/fuzzing/registry/FuzzerRegistry.h
extra : rebase_source : 7d0511ca0591dbf4d099376011402e063a79ee3b
Jan de Mooij
Margareta Eliza Balazs
Doug Thayer
Andrew McCreight
Matt Howell
Edouard Oger
Chris H-C
Kartikaya Gupta
Dzmitry Malyshau
Noemi Erli
Brian Grinstead
Dan Minor
Rajdeep Nanua
Gregory Terzian
Thom Chiovoloni
Timur Borkhodoev
Simon Fraser
Andreea Pavel
Nick Alexander
Alexandre Poirot
arthur.iakab
Mike de Boer
Johan Lorenzo
Dorel Luca
Andi-Bogdan Postelnicu
Tim Nguyen
Emilio Cobos Álvarez
Marco Bonardo
Martin Stransky
Rofael Aleezada
Coroiu Cristina
Arjun Krishna Babu
Christian Holler