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
The pending transforms must have been computed using the older scroll offset
values, which means that updating the scroll offsets without recomputing the
transforms will make them wrong. If we do an empty transaction for the scroll
offset updates, the transforms will not get computed. This patch catches this
scenario and schedules a full paint instead of the empty transaction instead.
The case where the scroll offset is modified *before* the transform is already
handled by code in nsIFrame::TryUpdateTransformOnly.
MozReview-Commit-ID: I5s5J7BS1ru
This fixes an incremental layout bug, where the number of times we
reflow the frame affects its layout. This is because we make the
decisions about the vertical scrollbar before the horizontal scrollbar
(and, when making the decision, adjust mHelper.mScrollPort for the size
of the scrollbar). Thus, in order to avoid a situation where reflowing
the scrollframe once leads us to have no vertical scrollbar, but
reflowing it a second time leads us to add that scrollbar, we need to
retest for the need for a vertical scrollbar after we add the horizontal
one.
(It's possible there are some other missing cases here, but this is the
one that (a) already existed in the code and (b) is needed to fix the
reftest failure on Windows that I got on bug 1308876, in
layout/reftests/text-overflow/xulscroll.html .
The reftest here shows the bug even without bug 1308876 (though I
confirmed that only by loading the test and reference in a nightly
build, not in the reftest harness). I did test that, in combination
with bug 1308876, the test fails without the patch and passes with the
patch.
MozReview-Commit-ID: LhMi7LbmB6J
ScrollFrameHelper::DecideScrollableLayer doesn't get the actual value of usingDisplayPort/wasUsingDisplayPort if we are not painting to the window. It then sets mWillBuildScrollableLayer to usingDisplayPort. mWillBuildScrollableLayer is the value that determines if we are active and hence an ASR, we don't want to change that between paint display lists for an event handling display list.
We then want to condition uses of mWillBuildScrollableLayer and the return value of DecideScrollableLayer on if we want painting to the window so we get the same behaviour as before when not painting to the window.
