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
This patch disables the stdcxx-compat check for the sm-fuzzing build which
requires patching autospider as well. Furthermore, it switches the build
to linux64-clang-6-pre because the older clang 3.9 does not support trace-pc
instrumentation. Finally, it excludes fuzzing parts from the vanilla allocation
check.
MozReview-Commit-ID: FdhCIFdUore
--HG--
extra : rebase_source : c41bda01cb42f2ef0cd5a1675d88bdb55d9dc8c9
mozInlineSpellChecker listens to only DidSplitNode() and DidJoinNodes().
So, EditorBase should call them directly rather than treating it as an
nsIEditActionListener since its runtime cost becomes really cheaper.
Different from EditorSpellCheck, nobody creates instance of
nsIInlineSpellChecker. So, we can now stop supporting createInstance() for it
in chrome JS and should do this since EditorBase cannot support multiple
mozInlineSpellChecker instances without nsIEditActionListener interface.
Therefore, this patch removes the entry from factory.
MozReview-Commit-ID: W1CLdsJaaB
--HG--
extra : rebase_source : 2319999e4b1fc8978386c49236d5d24d78d86047
Currently, first edit action listener is always TextServicesDocument for
EditorBase::mInlineSpellChecker if spell check is enabled and it requires
only DidDeleteNode() and DidJoinNodes(). So, in most cases, EditorBase
should call only them to avoid running redundant for loops for
nsIEditActionListener methods.
This patch makes that EditorBase::AddEditActionListener() and
RemoveEditActionListener() check whether coming nsIEditActionListener is
TextServicesDocument for mInlineSpellChecker. If so, EditorBase should
store it as reference to TextServicesDocument. And when edit action occurs,
its DidDeleteNode() and DidJoinNodes() should be called directly.
Unfortunately, this patch makes TextServiceDocument's maintaining rules
complicated. However, it must be really rare case to add new edit action
listener because it's really old component.
Note that EditorSpellCheck may be created multiple instances for an editor
from chrome JS. Therefore, we need to keep TextServicesDocument being
derived from nsIEditActionListener because in such case, TextServicesDocument
for other EditorSpellCheck instances should be supported via
nsIEditActionListener even though such case makes EditorBase slower.
MozReview-Commit-ID: KtlXsBCOzKL
--HG--
extra : rebase_source : 6827ed09a028f2049fd7afba2f5116d092bd14e5
mozSpellChecker stores TextServicesDocument, EditorSpellCheck stores
mozSpellChecker and mozInlineSpellChecker stores EditorSpellCheck.
So, they should have accessors for their member. Then, EditorBase can
access all of them.
MozReview-Commit-ID: Igphm8nRqve
--HG--
extra : rebase_source : 0c70bf3e23f16ea6a97b49901f4b1c87e7da6d37
EditorBase::mInlineSpellChecker is always an instance of mozInlineSpellChecker.
Fortunately, it's easy to expose mozInlineSpellChecker.h. So, making EditorBase
store it as mozInlineSpellChecker directly, EditorBase can access any of
mozInlineSpellChecker, EditorSpellCheck, mozSpellChecker and
TextServicesDocument with new accessors created by following patch.
MozReview-Commit-ID: 2oyS5tPeQcg
--HG--
extra : rebase_source : a9ce2e4dbceff7ca800d34d60d56eba184298677
mozInlienSpellChecker::mSpellCheck and mozInlineSpellChecker::mPendingSpellCheck
are always instances of EditorSpellCheck because mozInlienSpellChecker creates
its instance. Therefore, making mozInlineSpellChecker store EditorSpellCheck
directly makes sense.
MozReview-Commit-ID: LTtEMZqMS9E
--HG--
extra : rebase_source : 94e4c4ada332e626d49de5782fca192fb7489064
For making mozInlineSpellChecker stores nsEditorSpellCheck directly, we need
to expose its header file. For doing that this patch renames the class to
mozilla::EditorSpellCheck and expose it as "mozilla/EditorSpellCheck.h".
MozReview-Commit-ID: 5H66Y2vVshu
--HG--
rename : editor/composer/nsEditorSpellCheck.cpp => editor/composer/EditorSpellCheck.cpp
rename : editor/composer/nsEditorSpellCheck.h => editor/composer/EditorSpellCheck.h
extra : rebase_source : 7940aa136df312cd43bf592df1e71d2ac6c5dec8
nsEditorSpellCheck::mSpellChecker is always mozSpellChecker because it's
created only by nsEditorSpellCheck. Additionally, mozSpellChecker.h is
already exposed. So, nsEditorSpellCheck can store it as mozSpellChecker
directly.
MozReview-Commit-ID: 2vyDe4plncM
--HG--
extra : rebase_source : 847b2f384163450ab44b94bc12ee489633a849b6
nsITextServicesDocument isn't used by anybody now. So, we can get rid of it.
Additionally, nsITextService and nsTextServicesFactory are not also used by
anybody. Therefore, this patch removes all of them.
MozReview-Commit-ID: KSbMdm7QPKF
--HG--
extra : rebase_source : 724a5f48ad49b4231bacf7fba32c6a35d90121d0
Now, TextServicesDocument can be treated by anybody. So, let's make
mozSpellChecker and nsEditorSpellChecker treat it directly instead of
nsITextServicesDocument.
MozReview-Commit-ID: 2tMy6y3i17b
--HG--
extra : rebase_source : 2e6c79355a5e0a7044fbea989ba414a7bf1a7d8d
For making nsTextServicesDocument accessible from anywhere directly, we need to
expose its header. Then, it should be in mozilla namespace.
This patch renames nsTextServicesDocument to mozilla::TextServicesDocument
and expose the header file as "mozilla/TextServicesDocument.h".
MozReview-Commit-ID: 9PmP73PXSJu
--HG--
rename : editor/txtsvc/nsTextServicesDocument.cpp => editor/txtsvc/TextServicesDocument.cpp
rename : editor/txtsvc/nsTextServicesDocument.h => editor/txtsvc/TextServicesDocument.h
extra : rebase_source : a12081434d0bc002e3675178486cc7f8eaaa3256
nsTextServicesDocument stores editor with nsWeakPtr for avoiding circular
reference. However, both TextEditor and nsTextServicesDocument are cycle
collectable. So, we don't need to worry about the issue and we can simply
make it store with RefPtr<TextEditor>. Then, we can make EditorBase and
nsTextServicesDocument access each other directly.
MozReview-Commit-ID: 9I4U8ivFlov
--HG--
extra : rebase_source : 4880c6f7d706acc70324f58aee70d4311db44059
So we can change a string in this file to force the use of new caches,
thus ensuring a clean break from one changeset to the next.
MozReview-Commit-ID: EZsR23a1PZE
--HG--
extra : amend_source : bf6a3c53ab14f2eb249fdf57ff70dce97388f0a0
Switch almost all builds currently using the desktop-build image to use
the right debian7-*-build image instead. The only exception is the rust
bindgen spidermonkey builds, that require cmake being installed, but I
don't want to add it to the base images because that involves risking a
cmake dependency unwantedly slipping in Firefox (rust-bindgen ironically
requires cmake to build a single C++ file...)
