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
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
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
--HG--
extra : rebase_source : e1fe6a775ad97e16a6d7cc224634ff962ccb0fbf
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
--HG--
extra : rebase_source : 5f2c869c0749c1e1473797f2e202c075907a45fd
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
--HG--
extra : rebase_source : 63fec656440c8bee322f069a4466a311ebcd0f7d
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.
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
In bug 1359868 we started to do this, but we bounded the pre-render region for
the entire scrollbar by the widget bounds, which is not helpful for tall
scrollframes with short thumbs.
This time, we are bounding the pre-render region of the thumb only, so a small
thumb will always be completely painted.
MozReview-Commit-ID: 5LuP5Lfahdm
--HG--
extra : rebase_source : 3ab45f979160d7991aec71020cf57c9a1e57d1ce
Timothy Nikkel
Markus Stange
Nicholas Nethercote
Matt Woodrow
Ting-Yu Lin
Miko Mynttinen
Ehsan Akhgari
Bobby Holley
Bas Schouten
Botond Ballo
Bevis Tseng
Sebastian Hengst
Jonathan Watt
Kartikaya Gupta
Daniel Holbert
L. David Baron
Carsten "Tomcat" Book
Sylvestre Ledru
Mats Palmgren
Bill McCloskey
Alexis Beingessner