nsICollation for macOS version uses ICU, so we should use it on all platform since nightly and aurora can use ICU on all platform.

MozReview-Commit-ID: 4nTzDCjOQXJ

--HG--
rename : intl/locale/tests/unit/test_collation_mac_icu.js => intl/locale/tests/unit/test_collation.js
extra : rebase_source : 3b47f9a521e79be929bb4c39d0c68b9438075e4c

nsCollation.cpp implements nsCollationFactory and nsCollation utils classes.
To remove nsIPlatfromCharset dependency, I would like to remove nsCollaction utils class.  So at first, I would like to rename it to nsCollactionFactory.cpp. (then, nsICollation implementation will be nsCollation.cpp)

MozReview-Commit-ID: FaG3vfzi9cl

--HG--
rename : intl/locale/nsCollation.cpp => intl/locale/nsCollationFactory.cpp
rename : intl/locale/nsCollation.h => intl/locale/nsCollationFactory.h
extra : rebase_source : 25eebf52634310891d1bbcc974635b5cc4b1c402

This makes the display-reflow information for
layout/reftests/w3c-css/submitted/css21/pagination/moz-css21-float-page-break-inside-avoid-4.html
more clear, since it means we include previously-omitted
inline-break-before statuses (not really inline in this case!), such as:
  status=[Complete=Y,NIF=N,Truncated=N,Break=B,FirstLetter=N]

It was useful when debugging various tests for bug 1308876.

MozReview-Commit-ID: AL38FH6wuOa

--HG--
extra : transplant_source : 15%21%86%3C%1B%5C%C5s%7C9%26%FEo%B5%20%F7%E6%E4x

The SurfaceCache can discard on any thread at any time. So we could be in the middle of advancing frames of a fully decoded animated image and then the frames could disappear out from under us.

Making the code deal with that kind of a situation would make the logic very complicated. So instead just look up the frames once and pass them around, that way they never change during while we are advancing the frame.

MozReview-Commit-ID: AqSOEdEZKIy

MozReview-Commit-ID: 102vRTuIhEh

MozReview-Commit-ID: I51NHlxv6Mp

Bug 1345119 - Part 1: Move functions out of grid-inspector into inspector for sharing with boxmodel. r=pbro

MozReview-Commit-ID: KlHinf9jgFX

MozReview-Commit-ID: 9QPwtwYfNa7

--HG--
extra : rebase_source : bd740815d460b4a536a42cd40f72c7cead5118fe

This is a kind of regression of bug 1088054 part 6.  If new block doesn't have child node, GetLastEditableChild will return null after landing bug 1088054. So, we should use new block when GetLastEditableChild returns null.

MozReview-Commit-ID: Gzt1Xp3Sl47
***
P1

MozReview-Commit-ID: 8LVp5qGnme4

--HG--
extra : rebase_source : f0ed76b65517168b6b11edf96164b3e596038fc1

MozReview-Commit-ID: 9tfJ4ekq7BR

After switching to loading content stylesheets asynchronously, there are no
longer any consumers that require a synchronous channel to load localized CSS,
so these workarounds are no longer necessary.

MozReview-Commit-ID: AwLSmYf9qL3

--HG--
extra : rebase_source : d5f34c37e91478bb656014d53011ba2f504fe0e8

Bug 1348442: Part 3 - Do not evict cached stylesheets while they're still being used by extant documents. r=aswan

There are some optimizations, both existing and under way, that allow us to
share some stylesheet data between documents that they're loaded into. Keeping
cached sheets around as long as they're still in use should be a net memory
savings.

MozReview-Commit-ID: HUZzs6HhuFM

--HG--
extra : rebase_source : c38c066584614c6ee6ad65f4ac4dae84f538d669

MozReview-Commit-ID: Dtci1mfQts0

--HG--
extra : rebase_source : f9f0907b1562c955f13c1a4cea470cf2a6c79155

MozReview-Commit-ID: 9vvCbYovyoN

--HG--
extra : rebase_source : cdbd1336d101c4fdc8fb7785a3d2988f773aacfc

MozReview-Commit-ID: 1BzLNbdXMfU

--HG--
extra : rebase_source : fbbf411098ad111056816e24f50c2e3e03ea80ae

These changes allow us to asynchronously load pre-loaded stylesheets, in a way
that's similar to ChromeUtils.compileScript. The new method returns a Promise
which resolves to the preloaded sheet once it's finished loading.

This will allow us to remove the last remaining use of synchronous channels in
moz-extension: URLs.

MozReview-Commit-ID: 7J52ff93YKT

--HG--
extra : rebase_source : 20fa013cdc7f5fbedb5ce671ede17765a2abbac2

Edit transactions should store their editor instance with strong reference and they should be released at destroying the editor.

MozReview-Commit-ID: D67KU8WFxyo

--HG--
extra : rebase_source : 28c8a37498cad9f2e308eb4416cef76cf395bb9c

When we shutdown the browser while the GMPService is active we can end up
leaking a GMPParent, GeckoMediaPluginServiceParent, and a Runnable. I tracked
this down to the runnable dispatched to the GMP thread in
GMPParent::ChildTerminated(). The dispatch of this runnable is failing as we
are dispatching the runnable to a reference of the GMP thread which we have
previously acquired, but that thread is now shutdown. So the dispatch fails,
and if you look in nsThread::DispatchInternal() you'll see that we deliberately
leak the runnable if dispatch fails! The runnable leaking means that the
references it holds to the GMPParent and the GMP service parent leak.

The solution in this patch is to not cache a reference to the GMP thread on the
GMPParent; instead we re-request the GMP thread from the GMPService when we
want it. This means that in the case where the browser is shutting down,
GMPParent::GMPThread() will return null, and we'll not leak the runnable. We'll
then follow the (hacky) shutdown path added in bug 1163239.

We also need to change GMPParent::GMPThread() and GMPContentParent::GMPThread()
to return a reference to the GMP thread with a refcount held on it, in order
to ensure we don't race with the GMP service shutting down the GMP thread
while we're trying to dispatch to in on shutdown.

MozReview-Commit-ID: CXv9VZqTRzY

--HG--
extra : rebase_source : e507e48ee633cad8911287fb7296bbb1679a7bcb

Bug 1315850 - Port the work around from Bug 1343140 to the new CDM video decoder architecture. r=gerald

MozReview-Commit-ID: EV0bieXIxYM

--HG--
extra : rebase_source : 404709f1aee80465a953fce1a1e715d49ebfbe35

X11.h #defines 'Status' and 'Failed' and 'Succeeded' which conflicts with
the enum in DetailedPromise. So rename the 'Status' enum in DetailedPromise
so that the build works on Linux.

Some of my changes here caused DetailedPromise to be included in more
places that it was before, which caused build failures on Linux.

MozReview-Commit-ID: KV5xKixXR3J

--HG--
extra : rebase_source : ef6cab901d74b78f613660f263f5e453d6044536

This is required for the browser clearing persistence tests to pass.

MozReview-Commit-ID: Ai9qc6Ds1IG

--HG--
extra : rebase_source : 80c2133e26742410fda983e3c18c35736fc013d0

MozReview-Commit-ID: 9gHcMZvmMfg

--HG--
extra : rebase_source : 186f35455264aaa144fd7b1887b8ca2476ac03b2

MozReview-Commit-ID: E82ETFS90eH

--HG--
extra : rebase_source : 6f0d72f76e313b55f7c905d5878c63b8d7292b1b

This severs the ChromiumCDMVideoDecoder's connection with the CDM. The CDM process
will shutdown when the MediaKeys also severs its connection.

MozReview-Commit-ID: Aqc4y5Nxjvc

--HG--
extra : rebase_source : 5a2f77ffe84f9b99b4668520c838b29a428578d3

MozReview-Commit-ID: 5RbrWyLglRf

--HG--
extra : rebase_source : 3f9636503523f0c6effab15fa89cce25a961a0b4

MozReview-Commit-ID: 3CzwfOCXGP

--HG--
extra : rebase_source : 8ee1ae28a36779484717c6b105ef7730dd1896b3

At this stage, I store video frames in memory in nsTArrays rather than in
shmems just so we can get this working. Once this is working, I'll follow up
with patches to switch to storing all large buffer traffic between the CDM and
other processes in shmems.

I'm not planning on preffing this new CDM path on until that's in place.

MozReview-Commit-ID: LSTb42msWQS

--HG--
extra : rebase_source : b7f162515a1a32b2c344c11d0fa5c7004cec2e15

MozReview-Commit-ID: 559SP0ECldq

--HG--
extra : rebase_source : b6d499cafef2d6a6558b0db703b60320dea67803

The MediaKeys accesses the ChromiumCDMProxy on the main thread. But the
ChromiumCDMVideoDecoder will need to access the ChromiumCDMProxy on the decode
task queue in order to get a reference to the ChromiumCDMParent so that it can
talk to the CDM (on the GMP thread).

Additionally we'll need to shutdown the ChromiumCDMProxy, and if we do that
on the main threrad while the ChromiumCDMVideoDecoder is trying to get the
ChromiumCDMParent reference, we could hit thread safety issues.

So we need to hold a lock while reading or writing from the ChromiumCDMProxy's
reference to the ChromiumCDMParent. So add a GetCDMParent() function to the
ChromiumCDMProxy which takes the lock while reading or writing the reference.

This means that the caller will always get a valid reference. There is no guarantee
that the ChromiumCDMParent isn't shutdown after the reference is taken; if that
happens, the ChromiumCDMParent returned will fail on all operations.

In a later patch in this series, the ChromiumCDMProxy will anull its reference
to the ChromiumCDMParent on shutdown, and cause GetCDMParent to return null.
So callers need to null check the return value of GetCDMParent.

MozReview-Commit-ID: 4xL41YbwkxL

--HG--
extra : rebase_source : aa854e9d88965d7da60231d6f6a3912bf6ad2eeb

MozReview-Commit-ID: 3xgFxg1WfmY

--HG--
extra : rebase_source : 018abf2b8e1b351a29ba62275a2681fe9ea4fc24

MozReview-Commit-ID: 6I9N1c1nNMF

--HG--
extra : rebase_source : 6c5a3706b37e122a67e5ec1670587f37e25a1bc6

This means the EME PDM implementation can safely tell when a CDMProxy is a
ChromiumCDMProxy, so we can create an appropriate MediaDataDecoder for it (in
the next patch).

MozReview-Commit-ID: CpL6QRa7SwJ

--HG--
extra : rebase_source : 3821c378c73067066f3cc67499680bdf546fb4f0

This ensures that when we're using the ChromiumAdapter that we actually ask it
whether it'll work, rather than asking the adapter we're not using.

MozReview-Commit-ID: 85nZPl9MdWa

--HG--
extra : rebase_source : 90de89bec9b004859c3c2c09ed8efbd255acc141

We still use the same EMEDecryptor MediaDataDecoder as is used by the existing
EME decrypting path.

MozReview-Commit-ID: 3pXPjChctLb

--HG--
extra : rebase_source : 67575a02290ddb871510dd88f59fdab77658b3ce

MozReview-Commit-ID: 2DcprLAE1bg

--HG--
extra : rebase_source : b7de793c7676ace43d34a9556ef803e1bd3df239

MozReview-Commit-ID: AzvypvetoOL

--HG--
extra : rebase_source : cf303b0d792dfd86f1056529eb4c081d84fc2e82

MozReview-Commit-ID: 6hLPFLFRD5I

--HG--
extra : rebase_source : 0931d65116bf0c499933efc58cae97b275b0ba85

This means the MediaKeys is able to create a CDM.

MozReview-Commit-ID: 94Xc7sCLhH3

--HG--
extra : rebase_source : 914db1f04e0770776ae25c7b8bdc59e729fe78d0