And propagate the new flag to servo if mRestyleForCSSRuleChanges is set.
MozReview-Commit-ID: HRZ5duYgciF
--HG--
extra : rebase_source : 65528ea0dfa21e84bb9184a849c72a5c322e306b
The difference is that PostRestyleEventForCSSRuleChanges sets
mRestyleForCSSRuleChanges true. In a subsequent patch,
we propagate a new TraversalRestyleBehavior flag to servo side
if mRestyleForCSSRuleChanges is true.
MozReview-Commit-ID: IKsBbm09uT9
--HG--
extra : rebase_source : 5014c0a978f98e81543ec7766d2daa415317069c
We need to request an animation-only restyle to force flush all throttled
animations on main thread when we handle an event with coordinates
(e.g. mouse event).
MozReview-Commit-ID: KkjeQVsLgTl
--HG--
extra : rebase_source : 314408062e719e9f52df9a6726e2f3dad817bbef
We need to retrieve the correct base style for Servo backend, so change
the return value to AnimationValue and update
KeyframeEffectReadOnly::BaseStyle().
MozReview-Commit-ID: 9FL3h1DLoJt
--HG--
extra : rebase_source : 42284c5fe8b8135910cde44b0815eb475ca2f1cc
Some changes to animations don't affect the computed style and yet still
require the layer to be updated. Therefore, we also need to call
AddLayerChangesForAnimation in ServoRestyleManager. In this patch, we
factor out this function from GeckoRestyleManager, so we can reuse it.
MozReview-Commit-ID: LL7D1oGS65l
--HG--
extra : rebase_source : cd028a3d8f5dc251ec6615918a0f9569f0af44f5
Functions like BuildDisplayListForStackingContext or BuildDisplayListForChild look
up EffectSet property several times in callees, such as IsTransformed() or
HasOpacity(), which is time wasting.
We should look up EffectSet just once, and pass the found one to all callees
that need it.
MozReview-Commit-ID: GZywm2UcpU7
--HG--
extra : rebase_source : 21f5dd0076a90d876a6df35eee2b886844b44f0a
FRAME_STATE_BIT of nsFrame and nsINode::mBoolFlags are both full, we need to
find another place to hold MAY_HAVE_OPACITY information.
nsINode::mSlots might be a choice, but since we always use this information in
painting, memory footprint of nsINode will become larger after this change.
So I decide to put this information right in EffectSet. The drawback of storing
this information in EffectSet is, although unnecessary Effect look-up is
prevented, we still need EffectSet property look-up in each time
HasOpacityInternal call, so we need Part 2.
Conceptually, Part 1 and Part 2 are independent.
MozReview-Commit-ID: 6sfBFSHjxQb
--HG--
extra : rebase_source : 394141cec3b44bb352297a0add8f9763d815bddb
This change does the following:
* Introduce a new smart pointer called CounterStylePtr which either
holds an AnonymousCounterStyle strongly, or a named CounterStyle
managed by CounterStyleManager weakly, and use it to replace all
RefPtr<CounterStyle> around the codebase.
* Rename CounterStyleManager::mCacheTable to mStyles to reflect the
fact that it is used to manage all styles, not just for caching.
* Add a retired styles list which collect all named CounterStyle
evicted from mStyles, and post a PostRefreshObserver to destroy
objects in that list after next flush.
* Remove helper functions for counter style in nsStyleList and expose
mCounterStyle directly, to make code simpler with the new pointer.
Reason for adding a new smart pointer type rather than making their
AddRef/Release behave like BuiltinCounterStyle is that, it is possible
that after a flush, some stale style structs may still be alive. They
can contain pointer to destroyed CounterStyle objects. Although the
actual content may never be accessed anymore, RefPtr may still access
the object for refcounting during destruction.
MozReview-Commit-ID: xxegwSDhNb
--HG--
extra : rebase_source : bb5443f0eb56eee51cbdfd08e0400335648610e8
Also, assert that this presContext is non-null (which we already implicitly
assume, when we dereference it without null-checking it).
MozReview-Commit-ID: IIYUqGQTOnb
--HG--
extra : rebase_source : 67cbf91fb2fdeb46352559fb519693d6d13d3224
If the percentage basis isn't provided it will be calculated from the ancestors
as before. Note that that algorithm is only valid if the frame's containing
block is the ancestor's content box, which isn't the case for grid items.
So grid layout MUST provide a percentage basis, although the given value may
be NS_UNCONSTRAINEDSIZE for either axis if the value is indefinite.
MozReview-Commit-ID: 7nvAuR43xfM
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
--HG--
extra : rebase_source : b02d516ea164fc567110338411bf6ba251d53dab
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
There are situations where events may be handled out-of-order. Allow
coalescing to happen backwards in time as well as forwards to cover them.
MozReview-Commit-ID: 3k7vNFxE1cz
--HG--
extra : rebase_source : 636a3671536747cf62cb410836b4c5a2275bbb49
Also, assert that this presContext is non-null (which we already implicitly
assume, when we dereference it without null-checking it).
MozReview-Commit-ID: IIYUqGQTOnb
--HG--
extra : rebase_source : 67cbf91fb2fdeb46352559fb519693d6d13d3224
Do not run ScriptRunners queued by DestroyPresShell() in the intermediate state
before we're done destroying PresShell, PresContext, ViewManager, etc.
MozReview-Commit-ID: LNP7Lp7zekS
This patch shouldn't affect behavior -- it just takes a latent opportunity for
simplification and removes an unused layer of indirection. These functions were
set up to look like they took outparams, but none of the callers were using the
value left in the outparam.
MozReview-Commit-ID: LaL7YiyVYS2
--HG--
extra : rebase_source : 28466d6ab36da2e3609e7ed0fdb51618e652c7f7
The call that's causing the crash seems to be [1], that is, we're trying to
recreate frames for the root element, which should always have a frame created
at the initialization of the PresShell.
So the function I removed in that bug had something like the following:
if (!mDidInitialize) {
// Nothing to do here. In fact, if we proceed and aContent is the
// root we will crash.
return NS_OK;
}
Which PostRecreateFramesFor doesn't guard against (because I thought it was not
needed, per tryserver results).
Sounds a lot like we do need that check, though I'd like to have a testcase
where it happens :(
[1]: http://searchfox.org/mozilla-central/rev/3dc6ceb42746ab40f1441e1e659ffb8f62ae78e3/layout/base/nsCSSFrameConstructor.cpp#2420
MozReview-Commit-ID: Lh6SohNmmI6
--HG--
extra : rebase_source : 5b7076f86d41f5489e47ca16ac2f3620812ee9e8
We want to see if we can drop support due to web pages not using it.
Edge and Safari already don't support it, and Chrome reports that usage
is low enough that they're willing to drop it. But telemetry doesn't
tell us about web usage if we're triggering it via our own internal
code.
MozReview-Commit-ID: 5YBfhQJExHC
--HG--
extra : rebase_source : fd359e3264ba96ef10617f4de767080c94b792fb
Per description in bug 1361072, this is the standard idiom to assign
outparam pointers of refcounted types.
MozReview-Commit-ID: 6kmDslMs94j
--HG--
extra : rebase_source : c151f0e6050cfd3ce1cf914eeb350166c539d160
Say there's a single lag event, a GC or a busy loop, during which the user
types several characters.
Is this one (lag) event? Several (input) events?
We have INPUT_EVENT_RESPONSE_MS which will accumulate several lagged events in
this case. However, that is more of an indication of how users use Firefox than
how good we've been at eliminating sources of lag.
INPUT_EVENT_RESPONSE_COALESCED_MS records the coalesced time spend waiting for
responses to input events. So in this case it will record one value for the
entire duration of the lag.
MozReview-Commit-ID: H5rYnhwF0q3
--HG--
extra : rebase_source : b9be179dac6c6a007d2835b909ec4ce71a3f1c90
This also happens to fix other bugs, like making display: contents pseudos
animatable, which weren't before.
MozReview-Commit-ID: LhwTPNbFvSZ
--HG--
extra : rebase_source : 785105b08d6bfa15ad257e61b769a263c6810ad0
It's not only inefficient, but also prone to buggyness. Since styles may not be
up-to-date when it happens.
Post a reconstruct instead, which ensures a style flush happens before running
frame construction.
MozReview-Commit-ID: DrakHsJv5fY
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
--HG--
extra : rebase_source : 11900af908654336cc2391ab9480542c5474e38f
Not all of them are initialized/used in all the paths, but worth doing it just
for sanity.
MozReview-Commit-ID: 2EsHQCc0U8P
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
This also moves the NoteStyleSheetsChanged to RecordStylesheetChange, which
makes more sense, and stopped special-casing author styles, since it's not
needed now.
MozReview-Commit-ID: 9WKFa0JxqlU
--HG--
extra : rebase_source : 5803620c98309bd2fbb542158e69ef3ddcee9a4b
We will use this later in this patch series to simplify the creation of SMIL's
ValueWrapper objects.
MozReview-Commit-ID: 7EF9CN2SdwQ
--HG--
extra : rebase_source : e7cf5adc4c3f72dcc4b99625a8d0cb1a2d17f7d4
I removed it, but seems it can be hit. It'd be nice to have a test-case where it
fails though...
MozReview-Commit-ID: 7Xa3dNHwFMn
--HG--
extra : rebase_source : 7f0d8df2f571b84745c41bf675f12a9340016775
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
This also adds assertions to ensure attributes and state don't change during
layout or frame construction.
MozReview-Commit-ID: BANcpxnRsYS
--HG--
extra : rebase_source : 5d1bc424d3ed90fda3047d3c92c09251346b7bec
Currently the profiler mostly uses an array of strings to represent which
features are available and in use. This patch changes the profiler core to use
a uint32_t bitfield, which is a much simpler and faster representation.
(nsProfiler and the profiler add-on still use the array of strings, alas.) The
new ProfilerFeature type defines the values in the bitfield.
One side-effect of this change is that profiler_feature_active() now can be
used to query all features. Previously it was just a subset.
Another side-effect is that profiler_get_available_features() no longer incorrectly
indicates support for Java and stack-walking when they aren't supported. (The
handling of task tracer support is unchanged, because the old code handled it
correctly.)
The two skipped tests (1 in layout/base/ and 1 in view/) both cause leaks while
running crashtests, so annotate them with a tracking bug (bug 1363000) filed.
MozReview-Commit-ID: GhSRt4wqu44
--HG--
extra : rebase_source : ed81c75251b35cee7f940b38e3998a6df3c1fcc6
We use RestyleManager::mAnimationGeneration as the animation index of a
new created transition, and Element.getAnimations() uses this index to
sort the order of transitions. We increase mAnimationGeneration one per
restyle cycle if there is any non-animation update.
MozReview-Commit-ID: KmirBzI7CXi
--HG--
extra : rebase_source : 6a9001ea99f86c25b1d8d0a822b51b8753248bfb
Probably GetAnimationCollection itself should assert against it, but that's a
bigger task right now...
MozReview-Commit-ID: JxFWXtgMAXy
--HG--
extra : rebase_source : 90ffd33e56dd8d285765bc7a06572b0ae229b5e7
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
