Due to an oversight in bug 1423370, the code I added was setting the
transform on a WebRenderLayerScrollData after initializing it, but the
initialization might have populated the transform. Thus the
transform-set that I added would have clobbered the transform. This
updates the code to combine the two transforms instead which avoids
the clobber.
MozReview-Commit-ID: 4mKJTLSMD9J
--HG--
extra : rebase_source : c486c5866739ab040d81f9f9a43b2b8a04c2d383
Instead of creating a new layer scroll data for every single
nsDisplayTransform item, we only create a new layer scroll data for
nsDisplayTransform items with perspective. In addition, we save the
transform from the non-perspective nsDisplayTransform items on the
StackingContextHelper, and then apply it to layer scroll data items that
are created by display items nested inside those nsDisplayTransforms.
This effectively makes two changes to the structure of the layer scroll
data sent to APZ:
(1) we will drop layer scroll data items for transforms that APZ doesn't
care about (i.e. the non-perspective ones that don't wrap APZ-relevant
display items).
(2) we will collapse layer scroll data items that only had a transform
into its descendant layer scroll data items. This should be functionally
equivalent, since the transform is still in the right place relative to
everything else.
The net result is fewer layer scroll data items.
MozReview-Commit-ID: HV6QPfuUrje
--HG--
extra : rebase_source : ecfe1810f9889e7ce5096e1bc42cc30a92b43b4a
Apparently applying it on an individual function inside the extern "C"
block doesn't work so we have to apply it to the whole block. But that's
better than applying it to the whole crate.
MozReview-Commit-ID: GUMliaZragl
--HG--
extra : rebase_source : d12ac26aea76bc7c4487e80e6066a016871d1d20
Instead of hard-cording the root scroll frame id, get the value from
WebRender. This was previously hard-coded to 0, so when WebRender
switched to using 1 for the root scroll frame id, the positioning of
sticky frames were broken in subtle ways. This happened because they
were being parented to a root reference frame (which now uses the 0 id)
instead of the root scroll frame.
MozReview-Commit-ID: 66ArgKHGpWE
--HG--
extra : rebase_source : ff6937bf7fc8d4472eb074d0466c8dcd6fba54a8
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
FrameProperties have Remove() and Delete() methods. If you call
Remove() you now own the result, therefore we should delete it.
MozReview-Commit-ID: FybBYcbIZIH
--HG--
extra : rebase_source : fe1dc29d5a9bf5bac7b35452d3ad49b8aa0beb6a
Previously CreateWebrenderCommands would use GetLayerState to determine whether to use Webrender or
take the fallback path. GetLayerState would then under some cases call CanOptimizeToImageLayer()
which would get the image container using the appropriate flags for sync decoding.
Now nsDisplayBackgroundImage only uses CanCreateWebrenderCommands, which doesn't pass the correct
flags to image container, leading to reftest failures in some cases. This commit fixes that.
MozReview-Commit-ID: KlslXVHlRi5
--HG--
extra : rebase_source : aacb5fcae966cb9af8d8607e6c10e4c0822ea88d
Currently, we use a simple merging algorithm, because the more
complicated ones didn't work.
This code won't actually be used until we do blob image invalidation
in a follow up.
MozReview-Commit-ID: Q2Em3QC195
We're not using named shared memory, and supporting only anonymous
shared memory allows using other backends that are more compatible
with preventing a process from accessing any shared memory it wasn't
explicitly granted (i.e., sandboxing).
Specifically: SharedMemory::Open is removed; SharedMemory::Create no
longer takes a name, no longer has the open_existing option which doesn't
apply to anonymous memory, and no longer supports read-only memory
(anonymous memory which can never have been written isn't very useful).
This patch also fixes some comments in what remains of SharedMemory::Create.
MozReview-Commit-ID: 4kBrURtxq20
--HG--
extra : rebase_source : f6b1fb2fc79b6e9cdd251b3d9041036c0be503f9
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
This just adds the boilerplate that goes with the new protocol, without
adding any of the actual messages. The protocol is managed by PGPU, and
there will be one instance per compositor. The parent side lives on the
main thread of the GPU process, and the child side lives on the main
thread of the UI process. The protocol is only instantiated if the GPU
process is active.
MozReview-Commit-ID: J4VzwmEfYTa
--HG--
extra : rebase_source : 397ddda8b0e76e5ed5f63783b1220ed7b4414d99
This is important because the RecvInitialize method in CompositorBridgeParent
is run via a sync IPC message, and so we are guaranteed that when return to the
caller in the UI process, the APZCTreeManager will have been created. This
ensures that when we create the APZInputBridge actors (which will happen on a
different top-level protocol, but be triggered after the sync RecvInitialize
is complete) we know that the concrete APZCTreeManager is ready for use.
MozReview-Commit-ID: KYDyJNXxQJm
--HG--
extra : rebase_source : f7bbd000a94e405322ceaed6823693e4a95c81d4
This separates the methods that are used to deliver input events
synchronously over IPDL to the compositor; this interface will be
remoted over a new APZInputBridge IPDL protocol in future patches.
MozReview-Commit-ID: 1f3V9SUKlfW
--HG--
rename : gfx/layers/apz/public/IAPZCTreeManager.cpp => gfx/layers/apz/src/APZInputBridge.cpp
extra : rebase_source : 523abce7949baf9e3b7803a61632eb4434a6967f
A couple of RemoteContentController methods get called on the controller
thread in the GPU process. This is the same as the compositor thread so
we could just do compositor-thread stuff here, but we will want to
support the controller thread being the main thread instead of the
compositor thread. So we detect those cases and bounce the message
accordingly.
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
Without this patch, UpdateZoomConstraints can get called on:
a) the compositor/sampler thread (over PAPZCTreeManager)
b) the controller thread which is also the UI process main thread (on
desktop platforms without a GPU process)
c) the UI process main thread when it's *not* the controller thread (on
Android).
Instead of having to reason about all these scenarios separately, we can
try to unify them a little bit by ensuring the function contents always
run on the sampler thread, which is the thread that seems to make the
most sense for it.
These two functions (UpdateWheelTransaction and ProcessUnhandledEvent)
are only ever called on the concrete APZCTreeManager when the APZ code
is living in the GPU process. This is because the calls are made by the
IAPZCTreeManager implementation which lives in the UI process, and
remoted over PAPZCTreeManager. So the assertion is safe, and will help
us guard against inadvertent breakage when we try making a different
thread the controller thread in the GPU process.
In addition, the WillHandleInput function can be called in the GPU
process on the compositor thread, but we will allow it to be called on
the main thread as well. In that case we need to ensure we don't try
running EventStateManager pref-reading code in the GPU process, and
instead preserve the current behaviour of just returning true.
This function is never actually called over IPDL. It is called directly
on the concrete APZCTreeManager instance by the
AndroidDynamicToolbarAnimator code, both of which live in the
compositor. So we don't need to expose this method on IAPZCTreeManager
or over PAPZCTreeManager.
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
This lets us avoid having to check whether we have the right one when getting them.
MozReview-Commit-ID: 9YDiSd7AekB
--HG--
extra : rebase_source : 4e9ce48075fa02eba83209f545181a0883e7551e
A couple of RemoteContentController methods get called on the controller
thread in the GPU process. This is the same as the compositor thread so
we could just do compositor-thread stuff here, but we will want to
support the controller thread being the main thread instead of the
compositor thread. So we detect those cases and bounce the message
accordingly.
MozReview-Commit-ID: 6kLqdl6jgO0
--HG--
extra : rebase_source : 04f0ce53e247f198527f001cd80b48b126d25f9d
These methods are already guaranteed to be called on the controller
thread.
MozReview-Commit-ID: 4pfUZe6cI8e
--HG--
extra : rebase_source : 9ad24c0bb2e45bbd63e0a2febc14391e1a28f274
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
MozReview-Commit-ID: 64LkHaFLIOl
--HG--
extra : rebase_source : 61f397c0e18f83c68c228879692c9d4767b25675
Without this patch, UpdateZoomConstraints can get called on:
a) the compositor/sampler thread (over PAPZCTreeManager)
b) the controller thread which is also the UI process main thread (on
desktop platforms without a GPU process)
c) the UI process main thread when it's *not* the controller thread (on
Android).
Instead of having to reason about all these scenarios separately, we can
try to unify them a little bit by ensuring the function contents always
run on the sampler thread, which is the thread that seems to make the
most sense for it.
MozReview-Commit-ID: 8V4WTNtST3d
--HG--
extra : rebase_source : c4ebda75657d906d318acc07c174e8f3f634d18f
These two functions (UpdateWheelTransaction and ProcessUnhandledEvent)
are only ever called on the concrete APZCTreeManager when the APZ code
is living in the GPU process. This is because the calls are made by the
IAPZCTreeManager implementation which lives in the UI process, and
remoted over PAPZCTreeManager. So the assertion is safe, and will help
us guard against inadvertent breakage when we try making a different
thread the controller thread in the GPU process.
In addition, the WillHandleInput function can be called in the GPU
process on the compositor thread, but we will allow it to be called on
the main thread as well. In that case we need to ensure we don't try
running EventStateManager pref-reading code in the GPU process, and
instead preserve the current behaviour of just returning true.
MozReview-Commit-ID: JFBX3NSXywn
--HG--
extra : rebase_source : 6718944034ec7b7223581e562aa59e9e79b54b53
This function is never actually called over IPDL. It is called directly
on the concrete APZCTreeManager instance by the
AndroidDynamicToolbarAnimator code, both of which live in the
compositor. So we don't need to expose this method on IAPZCTreeManager
or over PAPZCTreeManager.
MozReview-Commit-ID: 6fEkJpDDvhl
--HG--
extra : rebase_source : cff9bb8fa43698950388b77f782b0b3fe6ec119b
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
MozReview-Commit-ID: CB23MxGISeL
--HG--
extra : rebase_source : b3358202ec5fa27422c56ae1b0b2237dbc8e489b
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
MozReview-Commit-ID: LVVZLFxSuyj
--HG--
extra : rebase_source : 89e9c8824c31867ad92152ff9b496744a6afdd83
This code is unused now that ReadLockDescriptors are not sent in layer transactions.
--HG--
extra : rebase_source : 8cd25541b22c3151e2dbd2f8ea6d1119e2f26c94
extra : source : 99a2d26d1ba82ad34a6c27641500a424cda015c3
There can be something shuffling the iframe between the mouse event is sent and
the mouse event is received which makes us end up targeting the <body> instead
of the test target.
This can be reproduced with enough persistence either with and without the
patches from bug 1439875, at least on a headless build with rr chaos mode.
Move it to test_group_pointerevents in the apz tests to run it in a new window
and make it a bit more reliable.
MozReview-Commit-ID: BS6Es8iEmMY
- gfxVRExternal Enables other processes to present
real or simulated VR hardware to Firefox.
- This functionality is disabled by default, under
dom.vr.external.enabled.
- VRDisplayInfo, VRControllerInfo, and associated
structs have been restructured to ensure internal
state is not exposed via shmem interface.
- Some refactoring to convert structs to
POD types, enabling them to be located
in shmem and be memcpy'd.
- Work needed before unpreffing marked
with "TODO" comments.
MozReview-Commit-ID: FbsusbxuoQ8
--HG--
extra : rebase_source : 8a448169c3f47411c705a4d9fd462a1f9363dfd9
extra : amend_source : e6702549527292e2850d16e8f503f0be9848159f
In each case, the atom had an obvious name and a weird name. Where possible, I
kept the obvious name and commented out the weird name, viz:
- `mixed` over `_mixed` for "mixed"
- `el` over `el_` for "el"
- `other` over `other_` for "other"
- `remote` over `Remote` for "remote"
But for several of them I didn't do that, because the weird name is used
within the HTML5 parser -- which is a huge pain to modify because it involves
code generated by code from another repo -- so I kept the weird name and
commented out the obvious name, viz:
- `list_` over `list` for "list"
- `svgSwitch` over `_switch` for "switch"
- `set_` over `set` for "set"
MozReview-Commit-ID: Jp3CpdWXNDm
--HG--
extra : rebase_source : 421ce5316772f1951488307e81f2ceee696d363d
If we can assume that a layer being composited has an APZC at index i if and
only if the frame metrics at index i is scrollable, then we can do the
transformations in the next patch without any change in functionality.
MozReview-Commit-ID: FRkvhwdd3nh
--HG--
extra : rebase_source : f1bee292305730079b3208e447330028c1a40727
This makes more sense in APZCTreeManager, but is exposed back to
AsyncCompositionManager via APZSampler. This also makes the APZ code
better encapsulated since the method API exposed on APZSampler doesn't
need to take a AsyncPanZoomController; it can just take the
LayerMetricsWrapper instead.
MozReview-Commit-ID: 9yJJd3x8VhN
--HG--
extra : rebase_source : b6f81116183810df158d8cce72891bb2db458355
This should help us narrow down what's going wrong a bit.
MozReview-Commit-ID: 2Ah0nMCwv55
--HG--
extra : rebase_source : fae57d36fe28b364fc652fb0e32abbbf8da43b0e
If the GPU process restarts, the mLastAPZProcessedEvent gets reset to 1.
The code in Update() checks for this special case and resets the value
to the incoming content process sequence number. However, we before that
first call to Update() on the sampler thread, the FocusState might get calls
to ReceiveFocusChangingEvent(), which would be triggered by input events on
the controller thread. These input events would advance
mLastAPZProcessedEvent which would bypass the special case handling in
Update(). This can leave mLastAPZProcessedEvent at a lower value than
mLastContentProcessedEvent which triggers assertion failures.
This patch ensures that calls to ReceiveFocusChangingEvent() during this
initial state doesn't increment mLastAPZProcessedEvent, and so allows
the special case handling in Update() to work as expected. It also adds
the special case handling to the branch where the first Update() call
results in no focus target being selected.
MozReview-Commit-ID: 7P2O2qg0mXj
--HG--
extra : rebase_source : eb0655225eba55a7b1ad9bf16c7c8ecab3c0cc7b
Scrollable doesn't mean exactly the same thing as wheel-scrollable.
However, AsyncPanZoomController::CanScroll(const InputData& aEvent) mistakenly
calls CanScrollWithWheel without distinguishing between wheel scrolling and
non-wheel scrolling, which may potentially lead to wrong APZC targets during the
hittesting stage.
MozReview-Commit-ID: 6xXQdtObLwB
--HG--
extra : rebase_source : 1f4ee06b7d41213b2d6d85cdd1439a11b92b0e98
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
We can easily populate the mId with the correct layers id, which is the
root layer tree id from the CompositorBridgeParent. This eliminates a
bunch of special-case handling.
MozReview-Commit-ID: FEkboAGEhYO
--HG--
extra : rebase_source : 01e73d516e5742d586cbf6d8b6bc5c9f7d64f141
The change that was made in bug 1374166 was attempting to fix the
problem fixed by the previous patch, but didn't actually succeed (it
just made it less likely to occur). Now that we have the proper fix we
can revert that botched attempt to speed up the test a little bit.
MozReview-Commit-ID: 3hWZ6bFTdxb
--HG--
extra : rebase_source : 15a8c6e183a5d7a09527ac3857b0eefb563c5165
With e10s enabled, we need to make sure that not only has the content
process layer tree reached the compositor, but also that the parent
process layer tree with the correct RefLayer has reached the compositor.
This is important for some APZ tests which proceed on the assumption
that the content process has been composited.
MozReview-Commit-ID: D0peZsJMHNT
--HG--
extra : rebase_source : 487a11a5478416e275013941282ff8f7636fb67c
If we are registering a cleanup function inside a subtest (as we will do
in the next patch) then we need to make sure it gets cleaned up before
the subtest is unloaded. Otherwise the cleanup will be attempted when
the top-level test page is unloaded, at which point the subtest is long
gone, and that results in an error.
MozReview-Commit-ID: 828XddkOUlP
--HG--
extra : rebase_source : a4b64d41c0dfcc27941abbff7ffbde2c69513b58
This is functionally a no-op but it makes code cleaner, particularly
some of the changes in a future patch.
MozReview-Commit-ID: 5UoT3aNJaPz
--HG--
extra : rebase_source : 53dbabc53ce5fbb549fa66976b41799f03be201d
(This is a helper patch -- I'm splitting this into its own patch since it's
changing files in other directories, and also so that the main patches here
can be a bit more direct.)
Without this change, the other patches in this series would cause compile
failures in the headers that I'm fixing up here (because the other patches will
be removing #includes from some headers that these files were inadvertently
depending on).
As of this patch, ComputedTimingFunction.h will now be including:
- nsDebug.h to provide NS_ASSERTION
- nsStringFwd.h to provide a forward-declaration for "nsAString&"
- Assertions.h to provide MOZ_ASSERT
- Maybe.h to provide Maybe<ComputedTimingFunction>
(I think it's been leaning on nsTimingFunction.h's include of nsString.h to
indirectly provide these.)
FrameMetrics.h will now be including:
- PLDHashTable.h to provide PLDHashNumber
(I think it's been leaning on nsStyleCoord.h/nsStyleConsts.h to indirectly
provide this.)
MozReview-Commit-ID: AoFoEe9GisK
--HG--
extra : rebase_source : 63c69343acaf42511ebdeb0238f4385a0c6345a5
So that we don't need to include nsStyleStruct.h in gfx any more.
MozReview-Commit-ID: 6nOaAbssLCz
--HG--
extra : rebase_source : 9c195c90277a4584dc14a6949e9eea53bcd8487c
gcc for arm/aarch64 target doesn't allow -msse2 command line option and it
causes option error, not warning. So it should not add this option for
non-Intel platform.
MozReview-Commit-ID: 9E6SGBMkT94
--HG--
extra : rebase_source : 3bd8d2f11d108c7463134c34f679244e6f4f3531
These were mostly exported because APZCTreeManager included them and now
they don't need to be exported any more.
MozReview-Commit-ID: 8W3vKOvzYW3
--HG--
extra : rebase_source : 8da95a203692ab3a88d37e66071b914682b44f14
This also includes unified build fixes that were needed as a result of
the shuffling around.
MozReview-Commit-ID: 1AGG3DHnN1m
--HG--
extra : rebase_source : 7399cea6dff2bd91ab305dee22d93b32382cc0be
Callers should be using one of the more specific subinterfaces like
IAPZCTreeManager (for controller-API methods) or APZSampler (for
sampler-API methods). There's also a bunch of android-specific
dynamic toolbar code that uses this function - I don't want to
deal with that right now, so instead of removing it entirely we can just
make it Android-only.
MozReview-Commit-ID: I8DYWLYoFgP
--HG--
extra : rebase_source : 75e05825194f9c6843506bb5d82e1a0c6e2b08bb
Although CrossProcessCompositorBridgeParent still needs to create a
dummy APZCTreeManager of its own in place, we can at least stop it from
grabbing the "real" APZCTreeManager from CompositorBridgeParent, which
allows access to methods that might not be properly guarded with respect
to thread safety.
MozReview-Commit-ID: Btvez3OkFPs
--HG--
extra : rebase_source : a4bec1769ff2fb899bb2e65f99f8e715f9a94c44
This fixes PrintTargetWindows::BeginPrinting to detect when the
user cancels and have it return NS_ERROR_ABORT in that case.
The rest of the changes are simply making sure that the various
call points up the call stack don't print a warning message if
NS_ERROR_ABORT is returned up from
PrintTargetWindows::BeginPrinting.
MozReview-Commit-ID: 6xZ5SPje6TT
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
In bug 1447185 we end up drawing at very high resolution because the scale factor getting reset to 1.
MozReview-Commit-ID: IdipkU0jWCG
--HG--
extra : rebase_source : 8d6d693d54a49fcd772df2279aad83a69d084198
