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
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
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
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
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
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
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
Feature is mature and doesn't need pref.
In fact, it was not used in code anymore, only in tests.
MozReview-Commit-ID: AbH8OCiksDa
--HG--
extra : rebase_source : b9a7d18b3c1b948f213632a16d2152f80d676068
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
Most of it is automated by:
%s/eStyleContentType_/StyleContentType::/g
%s/nsStyleContentType/StyleContentType/g
But I removed some parentheses by hand.
Differential Revision: https://phabricator.services.mozilla.com/D1900
MozReview-Commit-ID: 3IcirjIYX5p
Dynamic changes are handled correctly because content property changes already
cause a reframe.
This implements the same bits as Blink / WebKit do (single content item which is
an image, otherwise gets ignored), except for the edge cases where you use this
on an image.
In order to handle the edge cases right, we completely isolate the
nsImageLoadingContent usage based on `mKind`.
Blink's and WebKit's behavior there makes no sense and it's erratic, what I
implemented is consistent (we apply to images as long as they don't generate a
box, and we don't look at alt text or broken icons), though I'll update to
whatever the WG decides in https://github.com/w3c/csswg-drafts/issues/2831 /
https://github.com/w3c/csswg-drafts/issues/2832.
I don't think it matters in terms of web compat in any case.
MozReview-Commit-ID: JUurhC60hWr
Kris Maglione
Emilio Cobos Álvarez
shindli
Daniel Holbert
Hiroyuki Ikezoe
Andreea Pavel
Gerald Squelart
Ting-Yu Lin
Mike Conley
Tanushree Podder
Margareta Eliza Balazs
Bogdan Tara
Andi-Bogdan Postelnicu
Gurzau Raul
Jan de Mooij
Cameron McCormack
Kashav Madan ext:(%2C%20Tanushree%20Podder%20%3Ctpodder%40mozilla.com%3E)
Kartikaya Gupta
Matt Woodrow
Bas Schouten
Brendan Dahl
Florian Quèze
Ciure Andrei
Olli Pettay
Simon Montagu
Mats Palmgren