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
It may be that when the frame is reconstructed after load, the frame gets shorter,
and the old scroll position cannot be restored, because it is out of bounds. In
such a case, we don't want to keep mRestorePos tracking the old scroll position,
because it can get incorrectly applied on a future frame reconstruction. Instead,
for scroll position restorations during frame reconstructions, we just try the
restore once and then clear mRestorePos.
MozReview-Commit-ID: BHoJHz0mGmf
nsComboboxControlFrame will need some place to store its dropped-down state.
Instead of using nsISupportsPRBool and SetStateProperty, just add a bool.
MozReview-Commit-ID: CEnshCbqEV1
--HG--
extra : rebase_source : 6c4cef994ef85a1de2ff3aa40ad70bb150af9d09
Kartikaya Gupta
Andi-Bogdan Postelnicu
Chris H-C
Botond Ballo
Eugen Sawin
Benoit Jacob
Nathan Froyd
Aryeh Gregor
Gervase Markham
Ehsan Akhgari
Michael Wu
Robert O'Callahan
Graeme McCutcheon
Daniel Holbert
gavin%gavinsharp.com
dbaron%dbaron.org
bryner%brianryner.com