These are supposed to be helper base classes that should not be instantiated
directly, so we shouldn't let it be possible to Concrete<T>::construct() them.
--HG--
extra : rebase_source : 1a136d2c9eee11c7bd5b0c96e596a43454aefcfa
PSM JS code already pass these rules, so enabling these rules will just help
catch future bugs.
MozReview-Commit-ID: AXM2VoG8jBP
--HG--
extra : transplant_source : 4h%89%5BV7%C6%FB%B2%80%CE%B16%DC%22%BA%20%09%FB%92
In nsIFrame::BuildDisplayListForChild for certain types of frames we create wrap list items to wrap the constructed display list to make those items inseperable.
We were using the current scroll clip by default when creating these items, but that scroll clip may not contain all the content in the display list if we traversed into an out of flow frame whose containing block is an ancestor of the current frame. The CurrentAncestorScrollClipForStackingContextContents keeps track of exactly this. (Its name might be a little misleading as we may not be dealing with a true stacking context here. Nevertheless it does contain the correct clip.)
We also need to initialize the value of mStackingContextAncestorSC when we create an AutoSaveRestore because we are now using that value sometimes without calling Enter/ExitStackingContext (which initializes mStackingContextAncestorSC).
The asserts are:
###!!! ASSERTION: Bounds computation mismatch: 'mContainerBounds.IsEqualInterior(mAccumulatedChildBounds)', /layout/base/FrameLayerBuilder.cpp, line 4887
###!!! ASSERTION: bad aListVisibleBounds: 'r.GetBounds().IsEqualInterior(aListVisibleBounds)', /layout/base/nsDisplayList.cpp, line 1637
They happen because we have a wrap list item that contains an out of flow frame with no saved clip data. So the patch for this bug changes the scroll clip of the wrap list item from the scroll clip induced by the root scroll frame to the null scroll clip. All of the display items that the wrap list contains have the root scroll frame scroll clip, so this causes the scroll clipped bounds for the wrap list item to expand to the whole content area. These expanded bounds of the wrap list item get incorporated into the bounds of a parent transform item. Later the wrap list item is flattened away, and so it's no longer around to provide the expanded bounds, leading to the assertions.
I've thought through options like changing how scroll clipped bounds work for wrap list items, but I can't seem to find any solution that would be consistent. The best thing would be to get the proper clip on out of flows we are going to descend into, but I can't think of a good way to do that either in this case (or in general).
note, as bug 1281004 is about to land, I might require a new patch as we move
away from legacy towards da futures!
this yielded:
current bbot opt routes:
"index.gecko.v2.try.revision.f40f15f50508b78e369c8ac5e6a8743bcd064193.mobile.android-api-15-opt",
"index.gecko.v2.try.pushdate.2016.07.11.20160711204636.mobile.android-api-15-opt",
"index.gecko.v2.try.latest.mobile.android-api-15-opt",
"index.buildbot.branches.try.android-api-15",
"index.buildbot.revisions.f40f15f50508b78e369c8ac5e6a8743bcd064193.try.android-api-15"
my patch tc opt routes:
"index.gecko.v1.try.revision.linux.f40f15f50508b78e369c8ac5e6a8743bcd064193.android-api-15.opt",
"index.gecko.v1.try.latest.linux.android-api-15.opt",
"index.buildbot.branches.try.android-api-15",
"index.buildbot.revisions.f40f15f50508b78e369c8ac5e6a8743bcd064193.try.android-api-15",
"tc-treeherder.v2.try.f40f15f50508b78e369c8ac5e6a8743bcd064193.133427",
"tc-treeherder-stage.v2.try.f40f15f50508b78e369c8ac5e6a8743bcd064193.133427",
"index.gecko.v2.try.revision.f40f15f50508b78e369c8ac5e6a8743bcd064193.mobile.android-api-15-opt",
"index.gecko.v2.try.pushdate.2016.07.11.20160711204636.mobile.android-api-15-opt",
"index.gecko.v2.try.latest.mobile.android-api-15-opt"
current bbot debug routes:
"index.gecko.v2.try.revision.f40f15f50508b78e369c8ac5e6a8743bcd064193.mobile.android-api-15-debug",
"index.gecko.v2.try.pushdate.2016.07.11.20160711204636.mobile.android-api-15-debug",
"index.gecko.v2.try.latest.mobile.android-api-15-debug",
"index.buildbot.branches.try.android-api-15-debug",
"index.buildbot.revisions.f40f15f50508b78e369c8ac5e6a8743bcd064193.try.android-api-15-debug"
my patch tc debug routes:
"index.gecko.v1.try.revision.linux.f40f15f50508b78e369c8ac5e6a8743bcd064193.android-api-15.debug",
"index.gecko.v1.try.latest.linux.android-api-15.debug",
"index.buildbot.branches.try.android-api-15-debug",
"index.buildbot.revisions.f40f15f50508b78e369c8ac5e6a8743bcd064193.try.android-api-15-debug",
"tc-treeherder.v2.try.f40f15f50508b78e369c8ac5e6a8743bcd064193.133427",
"tc-treeherder-stage.v2.try.f40f15f50508b78e369c8ac5e6a8743bcd064193.133427",
"index.gecko.v2.try.revision.f40f15f50508b78e369c8ac5e6a8743bcd064193.mobile.android-api-15-debug",
"index.gecko.v2.try.pushdate.2016.07.11.20160711204636.mobile.android-api-15-debug",
"index.gecko.v2.try.latest.mobile.android-api-15-debug"
so all looks well and as a bonus, the index.buildbot routes now match too.
MozReview-Commit-ID: 5HilJOpONst
--HG--
extra : rebase_source : 24a3c895681284a8dca16cbf3b2a47b66eaa1f08
extra : amend_source : b8b8b91c9787e26a6dd6d54fbe39cb9cb515056b
Because bug 1282866 removed Qt support but missed a bunch of things.
* * *
Bug 1285554 - more
--HG--
extra : rebase_source : c48d2485f1fdf1c961e08d91651bbca41e3a1a53
We still want to keep ApplyPointerLock asynchronous so that the timing
when pointer lock takes effect is not changed by this patch.
MozReview-Commit-ID: EA8c6uzOd8F
--HG--
extra : rebase_source : 1d6355b618e67ff42c65d8088d3ccb1dca339401
extra : source : 98e099aad4b57295ffdce68a0140179d50bfd044
This code is no longer needed as we are always granting pointerlock request.
MozReview-Commit-ID: 3HVo3CddqWY
--HG--
extra : rebase_source : 53e72af037007d5d490cb9cb449492437e4c4714
extra : source : ce74d9d66912b6dfbe8e1379228b742baff119c3