We want local source directory paths to take precedence over system
paths so system installed packages don't get used.
MozReview-Commit-ID: FIZ0RxqZj78
--HG--
extra : rebase_source : e8d484ea0c8a0bdb1df10375317f6b2c349b9162
For some reason libfontconfig really Needs To Know.
MozReview-Commit-ID: KSET8D5h9xf
--HG--
extra : rebase_source : 10c5df6a4b8b85be120a9828686d0c63e3fff5d4
Log a message when shutting down a service worker with pending promises.
Looks like:
Terminating ServiceWorker for scope
‘http://mochi.test:8888/tests/dom/workers/test/serviceworkers/’ with
pending waitUntil/respondWith promises because of grace timeout.
Add an error message of the following form for when a register/update job
fails for network reasons:
Failed to register/update a ServiceWorker for scope
‘http://mochi.test:8888/tests/dom/workers/test/serviceworkers/network_error/’:
Load failed with status 404 for script
‘http://mochi.test:8888/tests/dom/workers/test/serviceworkers/404.js’.
A mochitest is added that verifies this.
To simplify the process of logging error messages, ServiceWorkerManager gains
a new LocalizeAndReportToAllClients method that always provides the SW scope as
the first argument to the localized string since all good error messages should
include it.
Its argument list takes an nsTArray<nsString> in order to reduce the potential
for use-after-free scenarios from the char16_t** signature that unfortunately
has rippled outwards from the nsIStringBundle interface. This potentially
results in more memory allocation and byte shuffling than is strictly
necessary, but we're also talking about rare error logging where it's
better to optimize for easily adding the messages without needing to get hung
up on the life-cycle of temporaries.
nsTArray gained a std::initializer_list in bug 1228641. It is explicit, so
inline argument usages may take a form along the lines of:
`nsTArray<nsString> { string1, string2, ... }`
This change did necessitate a change to nsContentUtils to add an nsTArray
variant of FormatLocalizedString since the existing public function was
slightly too clever. It used a template function to statically acquire the
number of arguments at compile time, which is not compatible with the dynamic
nsTArray usage. Since nsTArray may be useful to other consumers as well, I
placed the conversion logic in nsContentUtils.
B2g came with its own version of 'libgabi++' in its toolchain. Gecko
on b2g isn't build any longer with this toolchain. With this patch
applied, Gecko's internal version of 'libgabi++' is used for building.
MozReview-Commit-ID: KU4OBYQ6cAW
B2g now has 'OS_TARGET' set to 'Android'. This patch merges Android
and Gonk branches in the build scripts where possible.
MozReview-Commit-ID: 9hKA0Gc62Xc
Android and b2g have duplicated linker flags and libraries. This patch
removes the duplicates from b2g scripts. The library 'log' is now listed
in the correct variable 'LIBS'.
MozReview-Commit-ID: EtVzZpoXkdK
Not all Android releases come with their own platform release. This patch adds
a switch statement to MOZ_ANDROID_NDK to use the previous platform release in
this case.
For several tests, the autoconf script 'old-configure.in' uses an internal
variable 'ANDROID_VERSION'. The stored value comes from the environment
variable 'PLATFORM_SDK_VERSION'. This patch replaces 'ANDROID_VERSION' by
'android_version', which is defined by MOZ_ANDROID_NDK from a command-line
parameter.
MozReview-Commit-ID: EbDgZX2aJgJ
Necko's build scripts already handle include search paths for mDNS
libraries on b2g. This patch removes similar code from the configure
script.
MozReview-Commit-ID: DXMeZmi4weK
Bluetooth availability depends on available driver; not the base system's
version. This patch separates both. Following other modules, it also moves
search-path setup for BT header files into the affected moz.build scripts.
MozReview-Commit-ID: 2hzjcJVTaLY
This is a regression from bug 1162358.
We must be hitting the #ifndef SHMEM_ALLOC_IN_CHILD block in
GMPVideoDecoderChild::Alloc() with multiple allocs doing intr calls at once.
If this happens when a DecodingComplete() comes in, we'll end up sending one
task to re-call RecvDecodingComplete for every Alloc() blocked on an intr
response. This would result in us ending up trying to Send__delete__() in
RecvDecodingComplete() twice. Which causes the runtime abort we're seeing
here.
I think that could happen in the WidevineVideoDecoder if a Decode message comes
in, and goes into a ReturnOutput(), tries to alloc a frame and has to spin on
an intr message response, and another Decode message comes in and does the
same, so GMPVideoDecoderChild::mNeedShmemIntrCount will be 2, and then a
DecodingComplete comes in, and when two tasks on the stack in
GMPVideoDecoderChild::Alloc() finish they both end up dispatching a task to
re-call GMPVideoDecoderChild::RecvDecodingComplete(). So we end up trying to
Send__delete__() in RecvDecodingComplete() twice.
I expect the same problem exists in the GMPVideoEncoder too.
intr, or spinning event loops in general for that matter, is evil.
MozReview-Commit-ID: AKsvP62G3Cx
--HG--
extra : rebase_source : 53ca12dbbbf3ab071788e2322b7c926ec7c0325f
Jeff Gilbert
Gregory Szorc
Mark Banner
Kim Moir
Carsten "Tomcat" Book
Andrea Marchesini
Sebastian Hengst
Gian-Carlo Pascutto
Andrew Sutherland
Matt Woodrow
stefanh@inbox.com
Wes Kocher
Benoit Girard
Timothy Nikkel
Mike Conley
JW Wang
Patrick McManus
Thomas Zimmermann
Nathan Hakkakzadeh
Chris Pearce
David Keeler
Jared Wein
Phil Ringnalda