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
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
