Since fixed position elements are now scrollable, we need to ensure that they're
drawn using the layout viewport size instead of only the SPC-SPS, since
otherwise they'd be inaccurately clipped when scrolled.
MozReview-Commit-ID: 4p3pWnwluvz
--HG--
extra : rebase_source : f5bc1eae9bf2c8f4b9f78675e9da071de012160e
Thought I had to update this as well, but nope. When basically any style changes
we already update transitions.
needs_transitions_update already handles the physical mapping changing by
checking whether any transition for the physical property remain there or not.
MozReview-Commit-ID: 6vKwal4yzRU
The setup is that AnimationValue only contains physical properties, and
we physicalize when building keyframes and transitions.
MozReview-Commit-ID: 9dI20N0LFrk
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
Effectively we compute the diff by lopping off the rounded part
of each rect where appropriate. This gets a bit weird to think
about with very mismatched radii, but I think it works out(?)
MozReview-Commit-ID: 472gx7Hw1Br
--HG--
extra : rebase_source : 817a84d78c98ac99797ab73b89f8c667189767d1
I also tried to avoid this change but, again, given the number of times I was
repeating the same pattern of defining a static method just to forward a
callback to an instance method, decided it was probably necessary. Without an
easy way to do this, people are more likely to register observers rather than
callbacks, for which we'll wind up paying a continued memory and performance
penalty.
This patch adds a helper which creates a type-safe preference callback
function which forwards calls to an instance method on its closure object.
The implementation is somewhat complicated, mainly due to the constraint that
unregistering a callback requires passing the exact same function pointer that
was used to register it. The patch achieves this by creating the callback
function as a template, with the method pointer as a template parameter. As
long as the Register and Unregister calls happen in the same translation unit,
the same template instance is guaranteed to be used for both.
The main difficulty is that, until C++ 17, there's no way match a value as a
template parameter unless you know its complete type, or can at least compute
its complete type based on earlier template parameters. That means that we
need a macro to extract the type of the method, and construct the template
with the full set of explicit parameters.
MozReview-Commit-ID: 10N3R2SRtPc
--HG--
extra : rebase_source : 7d0a8ddeb77e01d4a6f421459514e93bc0875598
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
nsComputedDOMStyle is currently one of the biggest sources of pref callback
memory overhead. It currently registers about 5KB of callbacks per process. A
lot of that has to do with it registering multiple callbacks for the same
preference. But even with that problem fixed, we can do better by registering
a single callback for all observed preferences.
This patch does that, but also adds the optimization of deduplicating the list
of observed preferences to avoid wasted cycles needlessly matching against
many identical strings.
MozReview-Commit-ID: LZNgd7cAwo2
--HG--
extra : rebase_source : b73f8a17427bd01c362050d1a7c66e3f6e62332b
Most of the removed tests are specific to listbox code, some are related to fixes already covered elsewhere, and some have no associated fix and were originally checked in just for good measure.
MozReview-Commit-ID: 3AQXoKy6HhU
--HG--
extra : rebase_source : 88781275bfdb436c0bb4249972435ad74e95002e
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
Such messages happen intermittently on Android, presumably from bfcache being
purged due to memory pressure (which would then cause the back() operation
behave like a fresh load). So on Android, we'll now treat these redundant
messages as a "todo()" failure, to indicate that something went wrong but avoid
turning the testsuite orange.
MozReview-Commit-ID: GkaxB06vL7q
--HG--
extra : rebase_source : 64c0c0a41452d573062774b2300a26aad179b309
Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
--HG--
extra : rebase_source : 7120e9f462309d1c4efe995ef64aeead9e29ff8f
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 : 0c77a60918a365eb907327e16ff7253df955cf17
Similar to lines (see previous patch), floats from next-in-flow or overflow
frames have probably not been marked dirty (as ReflowInput hasn't dealt with
them when it was constructed), so we need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first
floats from the previous column they will not be reflowed as needed.
MozReview-Commit-ID: KKrwtzeQMrI
--HG--
extra : rebase_source : 2b1abb27e9a6ef248a90254b8b56c05207ae25e6
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
--HG--
extra : rebase_source : 0198b291a1b50441188e050dd5bcb2c06694df81
Add an anonymous XUL tooltip node to toplevel non-XUL windows. Setup a
nsXULTooltipListener on non-XUL nsXULWindows. Make nsXULTooltipListener
always use the default tooltip in the non-XUL case.
MozReview-Commit-ID: Koe5m8PwMQM
--HG--
extra : rebase_source : 242180e957758b51c589452e35deadac5ab06d9e
Added a data member to nsIPresShell to store the visual viewport offset. APZ
will update the visual viewport offset in the presShell for root scroll frames
on every repaint request.
MozReview-Commit-ID: Ksou43hrE6H
--HG--
extra : rebase_source : 812c88efc7556c4bff2a62834cfaaec6e6945093
Many tests set the dom.animations-api.core.enabled pref to true when all they
really require are the features covered by the dom.element-animate.core.enabled
pref. Now that we have removed that pref and permanently enabled that
functionality we can drop the annotations from such tests.
MozReview-Commit-ID: CGOLp6pVFLE
--HG--
extra : rebase_source : e298e9404d76d55421d9ca4b514410d02cc243b1
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
We need to call ReadTests because otherwise we wouldn't recompute `g.urls`.
Similarly, we don't want to throw when there are no remaining reftests, since we
handle that case properly.
Differential Revision: https://phabricator.services.mozilla.com/D2069
--HG--
extra : moz-landing-system : lando
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
For example, if we set a transform to rotate3d(0, 0, 1e50, 45deg), the
expected normalized rotate axis is (0, 0, 1).
However, the length is larger than the maximum of float, so the actual value is
(0/inf, 0/inf, 1e50/inf) == (0, 0, 0). Therefore, we scale the vector before
doing normalization to avoid getting a zero vector.
MozReview-Commit-ID: 5LUDWD4RuNj
--HG--
extra : rebase_source : eb82f0b3979bf6ea3cd11b643ebb30a49edc24f8
It's causing cache misses which are showing up in profiles of the displaylist
mutate test case.
To avoid checking Disconnected(), we can destroy the DisplayItemData
and unset the item's pointer to it, rather than calling Disconnect()
in the first place.
To avoid fetching the LayerManager (to compare with mRetainingManager)
we can store this value on the display item along with the
DisplayItemData.
This change ensures that if a nsDisplayItem holds a pointer to a
DisplayItemData then that DisplayItemData holds a pointer back, and
vice-versa.
MozReview-Commit-ID: AAVAs8c0CQY
--HG--
extra : rebase_source : e60c378877618592f311e690219099b1cfc4c9d4
I've tried to unsuccessfully reproduce the same kind of failures locally under
rr with this patch applied, so that's a good sign.
This should fix the case where we don't invalidate from AttemptPartialUpdate
while trying to sync-decode.
This is a clear part of the problem, though not sure yet if it'll fix all the
issues we see in these tests. In any case I want to investigate those
separately.
Differential Revision: https://phabricator.services.mozilla.com/D2068
MozReview-Commit-ID: H7OEvbQUues
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
This allows us to call emplace_back, saving us a move.
MozReview-Commit-ID: 4wRiAxl7LSN
--HG--
extra : rebase_source : 0ea07c896c2807a65ad7493a22b8e2b61e68aa01
Create an anonymous popupgroup element during the creation of a top level
chrome privileged nsCanvasFrame. Implement nsIRootBox for nsCanvasFrame to store
the popup set frame. Adjust nsIRootBox::GetRootBox to be able to find the
popupset frame in a non-xul frame layout.
MozReview-Commit-ID: HCbPgQb4uil
--HG--
extra : rebase_source : 26c06243a477a07e3df2b1136ac5f636d4363b40
This allows us to call emplace_back, saving us a move.
MozReview-Commit-ID: 4wRiAxl7LSN
--HG--
extra : rebase_source : 48a0eee8f61f568e0910476dbf672cb43827187e
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
mMostRecentRefresh is changed not only in Tick() but also in
EnsureTimerStarted(). In the case where it happens in Tick() refresh observers
can know it through WillRefresh(), but there is no way in the case of
EnsureTimerStarted(). This patch introduces a new abstract class to be notified
when mMostRecentRefresh was changed in EnsureTimerStarted() so that animations
can use the *real* most recent refresh time until the next tick happens.
The reason why we have another observer array in parallel with existing array
(mObservers) is that the refresh driver should stop the timer if there is no
normal observes but there are still any timer adjustment observes.
MozReview-Commit-ID: FaDcl5GrvI3
--HG--
extra : rebase_source : a6a362366f4eda9fb51003ef4cff5bea886836f0
Create an anonymous popupgroup element during the creation of a top level
chrome privileged nsCanvasFrame. Implement nsIRootBox for nsCanvasFrame to store
the popup set frame. Adjust nsIRootBox::GetRootBox to be able to find the
popupset frame in a non-xul frame layout.
MozReview-Commit-ID: HCbPgQb4uil
--HG--
extra : rebase_source : f56b1641f2ced53c22d464f331bdbe2c2e8afe86