There are non-cost reference return values on IPDL structs. We should take
advantage of them in order not to recopy everything everytime something
changes.
MozReview-Commit-ID: D4hG2moE3f
--HG--
extra : rebase_source : 4edca9b1a808f99dd60be908bbb197757bf9b90a
This patch also adds some Set*InAnyProcess() methods, and makes nsPrefBranch a
friend of Preferences so it can call those methods.
And it moves the thin Set*() wrapper functions to Preferences.h, alongside
SetUint().
MozReview-Commit-ID: 88HhmcTFZNc
--HG--
extra : rebase_source : 88a854d52afce86d93008a6e1a4b5f32bcf24a1a
This will allow other functions to be moved into Preferences and be marked as
`private` in subsequent patches.
The patch also renames SetPrefValue() as SetValueFromDom(), because that's a
clearer name.
MozReview-Commit-ID: CB1xmPSmac6
--HG--
extra : rebase_source : 0d597a800f2295c04af26d5abaac4aea0e0d3373
It's a `final` class, so there's no need for `protected`.
MozReview-Commit-ID: 7n4DLpXo0el
--HG--
extra : rebase_source : b2d3eb9cf0e912689efa29d2255cc018fd8a7c64
Find out where we use MayHaveTransformAnimation in EffectSet
and change them to MayHaveTransformAnimation in nsIFrame.
MozReview-Commit-ID: GhkztK8JtNa
There are two places where I have to cache the status of MayHaveOpacityAnimation
and MayHaveTransformAnimation. First place is in |nsIFrame:init()| where an
element is associated with a frame. Second place is in
|KeyframeEffectReadOnly::UpdateEffectSet()| where the script can add animations
on element.
btw I keep the original two flags of MayHaveOpacityAnimation and
MayHaveTransformAnimation in EffectSet because there is no guarantee that
an element has been associated with a frame when we call to |UpdateEffectSet()|.
But we still want to keep the benefits that we can quickly look up
MayHaveOpacityAnimation or MayHaveTransformAnimation. So I keep them in
EffectSet and transfer the status into nsIFrame when we bind an element
to a frame in nsIFrame:Init().
MozReview-Commit-ID: JDwyAQQTKA7
This is unused for now, but will be necessary for nsPrefBranch::Set*() to call
into Preferences::Set*().
The patch also renames some arguments from aPref to aPrefName, because that's a
better name.
MozReview-Commit-ID: 2OPB7CHOgpw
--HG--
extra : rebase_source : 232b7be3c33d185f13ce86d91feea3b55069a4e6
This is nicer than a bool for tracking the Default vs. User distinction, and it
replaces the Preferences.cpp-only WhichValue type.
MozReview-Commit-ID: 8CrdDN2vBJQ
--HG--
extra : rebase_source : 0d49148c73e5aeb0a355a6d4189232c89295d2a7
Our toolchain detection logic checks whether we can reuse the target
C (resp. C++) compiler for the host compiler. This is generally only
applicable in the not-cross-compiling case, but we had special logic to
check for clang in the cross-compiling case and accept it, as clang is
able to generate code for multiple architectures from a single compiler
binary.
Our recent switch to clang on Android has exposed a problem in this
logic: we would never check whether the target clang, compiling for the
host, could actually find the host's headers. This was especially
problematic on OS X hosts, where the host clang contains special logic
to grovel inside the XCode installation to find C++ headers. The clang
from the NDK, however, was ignorant of the XCode installation.
Therefore, the NDK clang would happily compile code for the host, even
including C headers for the host, but would be hopelessly lost when it
came to compiling C++ headers during the actual build.
In hopes of mitigating this, we now include a check for a representative
header for C and C++ when checking compilers for each of those
languages. This check will detect such problems as the above, and will
also alert people to potentially misconfigured compilers in other
situations.
We need to modify our test framework to cope with headers being
included, since our mock environment isn't actually equipped with a full
set of compilers and headers.
Now that extra_toolchain_flags includes stlport_cppflags, there's no
reason bindgen_cflags_defaults should depend on them both. So remove
the stlport_cppflags dependency. (There's no harm to multiply-including
stlport_cppflags, but not repeating -I options is good practice.)
extra_toolchain_flags is used for compiling target-specific bits of code
elsewhere in configure. Very shortly, we'll need to compile bits of
code that depend on the C++ standard library, so we'll want to point the
compiler at the C++ standard library. Making extra_toolchain_flags
include stlport_cppflags is the best way to do that.
extra_toolchain_flags is going to depend on stlport_cppflags
momentarily, so this commit is just for moving code around. Note that
the diff shows other things moving *after* stlport_cppflags.
We compute the same set of data in extra_toolchain_flags as we were
computing in bindgen_cflags_defaults. We might as well reuse the former
to compute the latter.
This patch enables building of geckodriver in CI on Linux i686.
MozReview-Commit-ID: GkdHDJrzh2X
--HG--
extra : rebase_source : 3202702d8ae3423079aad512a3d7c8dc8e7408a3
b6adf66f34c6 (bug 1416052) changed the value for "fh" when this code
is called. It can now be an io.BytesIO. This type enforces that
arguments are bytes and doesn't perform automatic type coercion like
most other parts of Python 2.
self.topobjdir is a unicode. And unicode_literals isn't in effect
in this file. So convert self.topobjdir to bytes to make BytesIO
happy.
MozReview-Commit-ID: LrWTKFp3ZKT
--HG--
extra : rebase_source : dc8b9cabe199c78073c96b1c16f9960f92e399e4
The method doesn't use any MSG member, only dispatching a task.
MozReview-Commit-ID: 7uZbTvq9OQt
--HG--
extra : rebase_source : e12c5ffcb6479ab2bc06973121c291e759db23a4
mStreams should only ever be accessed on the MSG thread. However, under some shutdown circumstances, it can be accessed on the main thread while the MSG thread is still alive.
This will be corrected in bug 1408276.
MozReview-Commit-ID: 6xWzxxV1Dv3
--HG--
extra : rebase_source : bce92961609da6ea8609ec8ada5a8a30263a84c9
mForceShutdownTicket and mShutdownTimer are only ever accessed on the main thread. We don't need the use of the monitor to reset them.
MozReview-Commit-ID: 1DL8bLmzEH5
--HG--
extra : rebase_source : 84d56c7f4428143426cd22e88ef2912330efba4e
We only access mLifecycleState via a helper which strongly enforced how the member can be accessed.
Two non-safe accesses are corrected.
MozReview-Commit-ID: 6LYk7t4rSyB
--HG--
extra : rebase_source : 9727771e1b04ba1b39f5cf9a6cf94093b7e92b27
