Most of this patch is just mechanical changes, but note that this patch
now makes the mFlags in scrollbar-container nsDisplayOwnLayer instances
have one of the direction bits set. As a result, this requires changing
the implementation of nsDisplayOwnLayer::IsScrollThumbLayer().
MozReview-Commit-ID: 2BLdbpz5Sa8
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
This mostly restores us to the previous behaviour where we would set mWillBuildScrollableLayer to false for event handling display lists. But it's better because we don't keep flipping its value.
The real reason we want to do this is that it fixes bugs with event handling.
The variable usingDisplayPort was determining if we applied a clip to the displayport (and one other thing), and otherwise mWillBuildScrollableLayer was used to determine those type of things.
When https://hg.mozilla.org/mozilla-central/rev/4c8b85e80aeb of bug 1364295 landed it actually changed behaviour even though it was only supposed to simplify code. Before that changeset mWillBuildScrollableLayer was always set to false if we weren't painting to the window because we never considered whether a displayport was set. After that changeset we actually looked to see if a displayport was set and set mWillBuildScrollableLayer to true if we had a displayport even when we weren't painting to the window.
So we would have usingDisplayPort == false, and mWillBuildScrollableLayer == true. We fix that be getting rid of usingDisplayPort and using everywhere.
This means that after this patch and bug 1364295 we will build display lists for event handling with mWillBuildScrollableLayer == true where we had it false before. So another patch we could make is to make all uses of mWillBuildScrollableLayer also check if we are painting to the window.
The decision to expand the dirty rect to the displayport is still restricted to when we are painting to the window and happens in DecideScrollableLayer, so we don't regress bug 745936.
This change is effectively a no-op since usingDisplayPort is only true if IsPaintingToWindow() but we need it for the next patch. So I will explain why this patch is correct.
At first we set usingDisplayPort to whether or not we had a displayport, which makes sense. But then in https://hg.mozilla.org/mozilla-central/rev/372d32e0ea61 (bug 745936) we had to limit this to when we weren't handling events so we didn't override the event handling dirty/hit rect of size 1x1 with the entire displayport.
Then in https://hg.mozilla.org/mozilla-central/rev/254c675a98c5 (bug 980500) we added support for adding scrollbars when we are ignoring the current scroll frame. This was a hack for b2g (and maybe android, where it might still be required) since we shouldn't be drawing the scrollbars when we are specifically ignoring the scrollframe. Only android and b2g have ever used the "ignore scroll frame" mode for their main rendering, so the change was only relevant for them. This changeset simply copied the same condition for using a displayport (!aBuilder->IsForEventDelivery()) to determine when to add scrollbars.
Then in https://hg.mozilla.org/mozilla-central/rev/2dc71497e243 (bug 1073290) we determined that it is useless to use displayports when we aren't drawing to the window (and actually can cause problems), so we changed the condition to use a displayport to require painting to the window (which is more restrictive then just not for event handling). However this change understandably missed the changing the condition for adding scrollbars. Thus this patch.
The reason we need this is the next patch (essentially) removes the IsPaintingToWindow condition from usingDisplayPort, and then we will erroneously add scrollbars when doing drawWindow calls that also ask to ignore the root scroll frame.
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
And stop creating displayports during display list building.
One thing we can investigate in the future is whether we should use the value of mHaveScrollableDisplayPort stored on the display list builder retained between paints. If it's true then we could potentially skip this pass. It would mean that if there are large changes to the page we wouldn't set a displayport. And we'd need to make sure the value is cleared when we load a new page.
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
This ensures that if the scroll event triggers style changes, they are
reflected on the same paint.
This is accomplished by having the refresh driver fire scroll events as
an explicit step after FlushType::Style observers and rAF callbacks, and
before the actual style flush.
MozReview-Commit-ID: 4kgauD5SgVo
