This uses XPCOM to replace the default process selector with one that always
asks for a new process and then put the old one back again. This comes with a
test to prove that it works.
MozReview-Commit-ID: Bq6KP4VzP7W
--HG--
extra : rebase_source : 1ea86df2e2443be38cfae4e5f8c1336bf742157c
This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.
MozReview-Commit-ID: H0gF3FqZsU6
--HG--
extra : rebase_source : 3886b757f3476060067811dcb385967769a67023
This was working because of our unified build, but having
the correct definitions for all types used by the header
helps editor navigation tools.
MozReview-Commit-ID: LuWEeTIikla
--HG--
extra : rebase_source : 0046ec17ac45270adc771bd0cf77c8381f99737b
This moves those two functions from a single test to a VideoStreamHelper in a
common file, so they can be used when checking video flow in multiple tests.
It also implements a VideoFrameEmitter that provides tests with an easy to
access video source where VideoStreamHelper can verify flow on the sink.
MozReview-Commit-ID: Fin9eiVmBe
--HG--
extra : rebase_source : 8b62124b0182d7e7bd78788e031b2d2259db9e57
This was used only for B2G, was proprietary, and is causing issues, because
`AudioContext` can now have a parameter that is a property bag, per spec
(although we haven't implemented it at the moment).
MozReview-Commit-ID: 6LOlNp0cbfV
--HG--
extra : rebase_source : 48aa342213dba201c1062a08c7453acd16b8baea
In our current setup, in which links with an href attribute always match either
:link or :visited, no matter whether that attribute's value is a valid URI,
changes to the attribute always put the element into either the "match nothing"
state or the "match :link" state, via calls to Link::ResetLinkState.
The only thing FlushPendingLinkUpdates is needed for is (lazily, in case it
turns out to not be needed because the element got removed from the DOM anyway)
registering a history observer to switch the link state to :visited as needed.
This means that selector matching consumers that would never expose :visited
state to start with don't need to worry about calling FlushPendingLinkUpdates.
This allows more use of the implicit version of InvokeAsync() without specifying the storage types explicitly.
MozReview-Commit-ID: 40WisaVX8Jy
--HG--
extra : rebase_source : ba34515788f0bc8264fac9a6897e234966d8b762
extra : source : b651963fe562755c0b2998ae6a95ffad400060ad
The declarations of their refcounting methods already includes an owning
thread, so let's just piggyback on top of that to assert their owning
thread, rather than having separate fields and tests.
IMEStateManager should cache nsIWidget for sPresContext at caching sPresContext. Then, even if sPresContext has gone, IMEStateManager can clean up with the nsIWidget cache.
Unfortunately, editor has some bugs about calling IMEStateManager::UpdateIMEState(). That is, calling it *before* IMEStateManager::OnFocusChange(). In such case, this patch makes UpdateIMEState() ignore the call.
MozReview-Commit-ID: 1cydI03WyB8
Use the new helper functions instead of calling libvpx directly.
This simplifies adding other codecs in the future.
MozReview-Commit-ID: 8VX0d5S50EE
--HG--
extra : rebase_source : 34be2118bc5d1bfcb6237d7fbe67d8fbc5ef1508
Encapsulate code from WebMDemuxer to query keyframe and frame
resolution inside VPXDecoder, so we have a clean wrapper for
all the libvpx functions we use.
MozReview-Commit-ID: ASRRhNl0A41
--HG--
extra : rebase_source : e0a27e946a60e0c33ecf4908f1e09436f836e123
Use the enum we already have here instead of converting
to an int when we pass it around, giving us better
type checking.
MozReview-Commit-ID: Gj4xmtQnzw2
--HG--
extra : rebase_source : fc7769c9650c59f52bfd8611e6cabb8e5b6d7068
This simplifies the comparison and update logic.
MozReview-Commit-ID: A6YII8tlEUn
--HG--
extra : rebase_source : e225b34f91e12591d5872121e024ef29c63a11e0
Continue to allow non-multiprocessCompatible extensions in automation.
There are a ton of places that would need to be changed, many of which
will be changing soon anyway with the non-webextensions change in 57
so this is mostly the expedient route to keeping the tree green.
MozReview-Commit-ID: EZZoDVdhLfy
--HG--
extra : rebase_source : f83472bc1c88dd0deadbe485d9002499027ff07f
Since we now want to support APZ for remote frameloaders in popups, but do not
want to needlessly enable it in simple popup widgets which should never host
remote content, we need to prevent remote content from being loaded into those
popups.
MozReview-Commit-ID: WfjMC2p2eK
--HG--
extra : rebase_source : 51704fa761053e947a2c56706627c8ae903790ee
extra : histedit_source : 463b2c88c28476a824bc2951e0731453016aaa2b
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
--HG--
extra : rebase_source : 86bca4ae1c012ff1bb84a9ad796be311cfe580f6
extra : histedit_source : 19577d69430adc8cb38c195f13db2c6de6605c4c