Previously we weren't sending scroll position updates with origin nsGkAtoms::restore
over to the APZ at all, on the assumption that they should never clobber an APZ
scroll offset. However, there are scenarios where that is not true.
In particular, during a frame reconstruction, a layers update may be sent to the
compositor between the time a scrollframe has RestoreState() called on it, and
the time the scrollframe has ScrollToRestoredPosition() called on it. The layers
update that happens during this interval (correctly) sends a scroll position of
(0,0), and forces the APZ to scroll to that position. This is necessary to
prevent APZ from remaining at an invalid scroll offset while the frame is still
being rebuilt.
However, once ScrollToRestoredPosition() is called and the old scroll offset is
restored, that restored scroll position needs to get sent to the APZ in order to
have it properly restore to the original scroll position. In order to do this,
the main thread must flag the metrics with a scroll offset update. Since the user
may have scrolled concurrently in the compositor from the (0,0) position, we also
need to check for that case in the APZ code and avoid restoring the scroll
position. This is equivalent to the corresponding main-thread code in
ScrollToRestoredPosition().
MozReview-Commit-ID: LxRapVSrsJ3
This is a pre-patch for part 5, which is trying to make our code closer to the
spec. Some methods in KeyframeEffectReadOnly belong to AnimationEffectReadOnly,
so first, use AsKeyframeEffect() to access those keyframe-related methods, and
then add virtual methods for timing-related methods to AnimationEffectReadOnly.
MozReview-Commit-ID: 1srA1f8JYeN
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
This preference was added in bug 747274, and the need for it (i.e.,
having it default to a different value on Android) was removed a few
weeks later in bug 750598.
Whether we honor the preference depends on which drawing function we go
through, which bug 720531 will make even more inconsistent than it
already is (by causing it to be honored for border-image-repeat: space,
but not other values of border-image-repeat).
Rather than trying to clean it up, it seems best to remove it, since its
initial purpose appears to have been having a different default on
Android, which we longer need.
MozReview-Commit-ID: IFW2Ukwx4fH
This patch also renames:
EditorInputEventDispatcher -> mozilla::EditorInputEventDispatcher
And some variable names are renamed from aEditor or mEditor to aEditorBase or mEditorBase for making their types clearer.
MozReview-Commit-ID: 2FCXWpLMn8e
We want to know that an nsIFrame has a transform or opacity animations
regardless of its state, e.g., running on the main-thead, paused or
finished but in fill:forwards state, to create a stacking context
for the animation.
MozReview-Commit-ID: mNYsd5RO3u
