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
Also add a comment to AsyncDragMetrics documenting that mScrollbarDragOffset
is relative to the thumb's start offset.
MozReview-Commit-ID: uipsOCzs2N
--HG--
extra : rebase_source : 25183e22cb7ffb9995a2594d6aea106cdef7924a
To conserve space in LayerAttributes, we only store the extents along the
relevant axis.
MozReview-Commit-ID: GAL8Oa2NOde
--HG--
extra : rebase_source : 9420d0fb36175e190cbff6e162fd41d8e5240c81
This flag is set to false if there are any conditions that only the main
thread knows about that prevent the thumb from being async-dragged.
MozReview-Commit-ID: Gl7f7bY0QnA
--HG--
extra : rebase_source : 60ab680a3995e3b5c0e1b4482ca0e7142352bbd2
The patch also renames Layer::SetScrollbarData() to Layer::SetScrollThumbData()
for clarity.
MozReview-Commit-ID: DVwJ3DMl3Zs
--HG--
extra : rebase_source : 7b2bfccf1351c82bb16296635e69d5488c87a50f
Transparency is not handled correctly for composited popups on any platform,
but works with varying degrees of success on some platforms, for some popups.
Oddly, out of the three main desktop platforms, Linux seems to handle it the
best, so long as we render the popup as opaque, and let the platform
compositor handle the transparency.
MozReview-Commit-ID: E8NQlToUQq3
--HG--
extra : rebase_source : c77da6eed1e95769798a14e873798df920fcb9b7
There are several behaviors that we only need to apply to popups which are
known to contain remote content. And since those behaviors can cause issues
elsewhere, we need to be able to identify popups which should contain remote
content, and treat them specially, where appropriate.
MozReview-Commit-ID: EMFrSP8lZiD
--HG--
extra : rebase_source : 5ee9da422081098d8099a048c7704008a06a7241
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
The APZ scrolling codepath doesn't do the right thing for <listbox>
without special handling, so have it scroll in JS instead, like we
did in bug 1302736 for <tree>.
MozReview-Commit-ID: LWJCBfhZ3Hc
--HG--
extra : rebase_source : bb8b2f7e713d35822a956e08f4e0eed0557b07b3
Supporting custom scrollbar mediators would require having custom logic in APZ
for each custom mediator. Since custom mediators are only used by legacy XUL
elements (<listbox> and <tree>) that isn't worth implementing.
MozReview-Commit-ID: KtCUvtiR1qn
--HG--
extra : rebase_source : dfd301da4d6877dd636c9719df46409db260d94c
The flush was added due to the overflow/underflow events causing recursion in some cases. But if the events aren't fired there is no point in doing this. The password manager test is changed to flush since it relies on showing/hiding tree columns but currently doesn't wait for a relayout before asking for cell information.
In the new architecture of Quantum DOM, all timer callback need a
specified event target. So, we add the new document arg to Start
function to get the event target from it. And update all callers.
MozReview-Commit-ID: a482mukqGc
--HG--
extra : rebase_source : 36f9d47a4afd7c7113adf3f274656b694b8d0943
In the new architecture of Quantum DOM, all runnables need a name label.
So, we add the new string-label arg to Start function, and update all
callers.
MozReview-Commit-ID: G9LXFjtFcQv
--HG--
extra : rebase_source : a19b605013be56d01780c831d2a48ada8825b1c7
This patch makes nsRepeatService stop inheriting from nsITimerCallback.
We needed that inheritance for InitWithCallback, but we do not need it
for InitWithFuncCallback.
This patch also makes nsRepeatService singly-owned instead of being
refcounted, since we're left with only a single owning pointer.
MozReview-Commit-ID: Fl8beVC8kGH
--HG--
extra : rebase_source : 3b6223c8e4754a90d2fef460940fda4510310f95
This was added in
https://hg.mozilla.org/mozilla-central/rev/9eabf947efc3363a1bf79aa03c3053d184510846
for https://bugzilla.mozilla.org/show_bug.cgi?id=957445#c29 but the
|aShouldRepaint| out parameter is not handled, and the call has no side
effects.
WidgetStateChanged() in nsNativeThemeWin and nsNativeThemeCocoa do not request
repaint of the scrollbar nor otherwise handle curpos.
nsNativeThemeGTK::WidgetStateChanged() requests a repaint on some changes in
curpos only on scrollbar buttons.
MozReview-Commit-ID: 98iyhLMs7ja
--HG--
extra : rebase_source : 512e0d9e825975a33fadd51e7c69d1ea0fa1cbef