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
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
ScrollFrameActivityTracker::NotifyExpired() will be invoked by
nsExpirationTracker::TimerCallback() from an unlabeled runnable.
We provide a SystemGroup EventTarget for the invocation of this
callback since there's nothing within a page that would rely on
the timer firing at a particular time (i.e., it doesn't matter
when this timer's callback is scheduled, relative to other
runnables dispatched for the page).
MozReview-Commit-ID: 9QEjxCtFhve
--HG--
extra : rebase_source : 06b979835363b9c4288dd218d2a4ca2dc111169b
NotifyApproximateFrameVisibilityUpdate gets the displayport so we want the base rect set before calling it.
We also don't want to record the displayport if we ignored it in the actual visibility pass.
If we disable APZ on an individual scrollable element by setting the "disable APZ"
flag on the ScrollMetadata, we should also disable paint-skipping for that element.
If we don't do this, we end up in a situation where the APZ code is not applying
the async transform but is sending repaint requests expecting the main thread to
do repaints. Meanwhile the main-thread thinks that it can send empty transactions
and have APZ update the async transform (a.k.a. paint-skipping). So visually
neither APZ nor main-thread have an effect and the element doesn't appear to
scroll except with the tile-aligned displayport shifts. Disabling paint-skipping
on the element fixes the issue.
MozReview-Commit-ID: H4wpVLw8r8X
The scroll frame is almost always the content's primary frame and if so
it already has the correct style values and the nsFrame ctor has set
mWritingMode correctly based on those. For the edge cases where it's
not the primary frame, e.g. <fieldset style=overflow:scroll>, the UA
sheet specifies 'inherit' for the relevant properties so it has
the correct style values in this case too.
MozReview-Commit-ID: 1FMFNfF0IqU
This adds markers for FireScrollEvent, DispatchSynthMouseMove, ForwardTransaction, and NotifyDidPaint.
MozReview-Commit-ID: 9XahFGzIOls
--HG--
extra : rebase_source : 1985b2a11777a17dac621a35632f138a76224b0f
This patch is written by the following script with some manual adjustment to
the comment in nsRubyTextContainerFrame.cpp and nsRubyFrame.cpp, and
nsColumnSetFrame's constructor.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "nsReflowStatus *([a-zA-Z0-9]*) = NS_FRAME_COMPLETE" "nsReflowStatus \1"
rename "([a-zA-Z0-9.*]*) *= NS_FRAME_COMPLETE;" "\1.Reset();"
rename "([a-zA-Z0-9.*]*) == NS_FRAME_COMPLETE" "\1.IsEmpty()"
MozReview-Commit-ID: 9tqQAHvdQex
--HG--
extra : rebase_source : 3119776946dc2c8350098b7bf9f3ceff29bdffb5
Root frame containers really throw a wrench into the whole system.
MozReview-Commit-ID: 9066vWMYxxr
--HG--
extra : rebase_source : 7e79c1ffa1a327e0ee9f780885e2fae02b8846ed
This is the bulk of the changes.
- DisplayItemScrollClip is removed. Instead, we will have 1) ActiveScrolledRoot
and 2) DisplayItemClipChain.
- ActiveScrolledRoot points to a scroll frame and allows traversing up the
scroll frame chain.
- DisplayItemClipChain is a linked list of clips, each clip being associated
with the ActiveScrolledRoot that moves this clip.
- Each display item has an ActiveScrolledRoot and a clip chain.
- nsDisplayItem::GetClip returns the item of the clip chain that scrolls with
the item's ASR. The separation between "regular clip" and "scroll clips"
mostly goes away.
- Tracking clips in the display list builder's clip state happens very
similarly to how regular clips used to be tracked - there's a clip chain for
content descendants and a clip chain for containing block descendants. These
clip chains are intersected to create the combined clip chain.
- There are strict rules for the ASR of a container item: A container item's
ASR should be the innermost ASR which the item has finite clipped bounds with
respect to.
- At some point in the future, ASRs and AGRs should be reunified, but I haven't
done that yet, because I needed to limit the scope of the change.
MozReview-Commit-ID: KYEpWY7qgf2
--HG--
extra : rebase_source : c727f6300a35463750639e165bfa37374c06b851
If, within a single refresh driver tick, the scroll position is updated by JS
explicitly, and then subsequently also updated by a frame reconstruction, the
scroll origin from the former (nsGkAtoms::other) can get clobbered by the latter
(to nsGkAtoms::restore). The restore scroll origin is "weaker" in that it can
be ignored by the APZ code in some circumstances. This is undesirable because
it means the JS scroll update also gets ignored. This patch ensures that when
setting the scroll origin we don't do this clobbering of stronger origins with
weaker origins.
MozReview-Commit-ID: DA4EHp1Debu
--HG--
extra : rebase_source : 99fd1f91698a605792b2a622450f1ff31bc89101
