Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
--HG--
extra : rebase_source : 3c68ef330b1f263afa2fad9670a30b351b8dbf28
Now that all properties handle currentcolor via mozilla::StyleComplexColor,
unify test_currentcolor_transition() and test_true_currentcolor_transition()
into test_currentcolor_transition().
MozReview-Commit-ID: 81hlAgTotpL
--HG--
extra : rebase_source : 9c9744c3fe4e423451e5a581501c88539c9d591f
In some cases we get a gecko display list that looks like this:
WrapList with asr(<A>, <B>)
Item with asr (<B>) and clipchain(<something> [A])
In this case, we would initialize the WebRenderLayerScrollData for the
nested item using a stop-at ancestor of A (because that was the leafmost
ASR from the containing WrapList) but the item itself has an ASR of B,
which is an ancestor of A. So when walking up from B we'd never hit the
stop-at ancestor, and so we'd end up duplicating metrics from the
containing WRLSD onto the nested WRLSD. This generated an assertion
failure in the APZ code.
This patch detects this scenario and skips adding metrics on the nested
WRLSD. This produces an APZ tree equivalent to what the non-WebRender
path would produce.
MozReview-Commit-ID: 8eo6pzXXKBd
--HG--
extra : rebase_source : 0581c54c4d9fa6ca08249e42b306c7155022bec7
Instead of re-dispatch an untrusted event, simply make sure the keyboard event is handled
by the video controls.
MozReview-Commit-ID: 9Kj7E3UP77w
--HG--
extra : rebase_source : 8bbc787c7e5dd3d4351270b17f521f49b0f1a21c
There are 3 main components to this change:
a) Store the origin of the layout viewport in APZ (until now we only stored
it's size). This required updating the offset stored in mViewport, which
was previously (0, 0).
b) Adjust the layout viewport in APZ each time the visual viewport exceeds
the bounds of the layout viewport.
c) Update the main thread to store the layout viewport offset for the
RCD-RSF (currently it uses the layout viewport offset for overflow:hidden
pages, and the visual viewport offset otherwise).
MozReview-Commit-ID: 7AD8wvthh2m
--HG--
extra : rebase_source : df8704146740f4b2522c80b20b603617993b6c83
These epoch times were introduced for beforepaint event in bug 569520, and
haven't used since we dropped mozRequestAnimationFrame in bug 909154.
MozReview-Commit-ID: CGOGeH0rrdi
--HG--
extra : rebase_source : 43905538a39c9618d95cc0513f3ffa2cf813a970
The content of this element is always overridden and the "xul:button" display mode is unnecessary, so the binding can be removed. The styles that control color are moved to "richlistbox.css" in preparation for the removal of the "listbox" element.
MozReview-Commit-ID: 5pGVE6n34EL
--HG--
extra : rebase_source : 8c5e37736c92382486ac605cc2d30085c16b7de7
extra : source : 8be7c63ea5c620641816664d9be81e58a912f9f3
This gets set to a non-zero value when we have an inactive ContainerLayer ancestor (filter in this case).
The current code assumes we'd never call BuildLayer on an image when that happen, but we force the pseudo-active
state here because background-position is animated (all properties have a transition).
MozReview-Commit-ID: 6pL8EJTNgWy
--HG--
extra : rebase_source : 6370fc79d5f47f0b5c4bbe86c0b605b90256b653
In the case of an invalid clip-path, the browser is supposed to discard the
mask entirely. In the non-webrender codepath this would happen
implicitly because the computed MaskUsage would have no flags set, and
so no actions would be taken on the gfxContext which contained the
display items rasterized so far. In the WebRender codepath, though, we
invoke the code on a A8 drawtarget that's zero-filled, so if PaintMask
fails to rasterize anything into it, it gets treated as a "mask everything
out" mask. Instead, this patch makes it so that we detect the scenario
where the computed MaskUsage is a no-op, and ensure that we don't apply
the mask in that case.
An alternative approach considered was to initialize the A8 drawtarget to
white instead of black but in cases where there is an actual mask, the
rest of the code assumes it is zero-filled and so that doesn't work.
MozReview-Commit-ID: Hw7nCiUXVJl
--HG--
extra : rebase_source : 241d550fa0ed1b3bd088c73d9565b166acbcece8
I thought of just moving the tracking to nsImageFrame instead of
nsImageLoadingContent entirely, though that would mean I need to handle it also
in nsImageBoxFrame and nsSVGImageFrame, which was even more duplicated code.
Ideas for testing this welcome, though all our animated image test-cases are
borked (all reftests in image/test/reftest/apng are disabled, and all the ones
for gifs that have animations as well).
I'll cross-ref this bug and bug 1473651 so that we can write a test for this
once that's fixed.
Differential Revision: https://phabricator.services.mozilla.com/D1994
--HG--
extra : moz-landing-system : lando
