In the nsWindowMemoryReporter.cpp / nsArenaMemoryStats.h I'm only
including the concrete frame classes now - we obviously never have
instances of the other IDs so there's no need to collect stats for them.
MozReview-Commit-ID: 48uFCZ3xKBC
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 386a1b9fe5ffc5fefbf20678068573ea195043f0
This is less expensive than sending nsChangeHint_AllReflowHints, and it should
be sufficient since hiding/showing scrollbars is basically just changing the
available space.
MozReview-Commit-ID: 4KyyLzvplAN
--HG--
extra : rebase_source : 4ecb585961ae300e9016f93c4ae0b30fed738151
This patch doesn't affect behavior at all. It's simply adjusting the way we
express a bitmask, without modifying the actual value of that bitmask. The
intent of this change is to make this bitmask's definition as similar as
possible to the definition for its ISize (inline-axis) analog, so that it's
easy to compare the two.
MozReview-Commit-ID: FUJnBQm8hmJ
--HG--
extra : rebase_source : 400972b9af447721183769b603eedb9a9fd4c939
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 926f8442fbd17c7ffa7f72b6b4a515a28b9aa18b
The ignore-root-scroll-frame flag is generally needed on Fennec, or possibly
other zoom-enabled platforms, when we have them. It allows hit-testing things
outside the main thread's notion of what is visible, because that might occur
when the user zooms out.
For largely historical reasons, we are passing this flag around in other scenarios,
such as when doing hit-tests for touch events, because in the past touch events
and zooming only happened on Fennec, so it didn't matter. Now that we have
touch events enabled on other platforms, such as Windows, we need to make the
distinction clearer.
MozReview-Commit-ID: BlHjtjFYgzv
--HG--
extra : rebase_source : cbfeab4666b5556ba0b38f3abdf666d63945b9a1
When the counter style in the style struct changes, CalcDifference
would return ReconstructFrame, which should cause corresponding use
node to be reconstructed. That means a use node with retired counter
style should always be destroyed in the next flush, so it makes no
sense to reset them anymore.
However, we would still need to mark counter lists dirty because
otherwise their content may not get update when there are changes to
counter styles which are still valid.
MozReview-Commit-ID: FnBPx81StzG
--HG--
extra : rebase_source : 2adf7b64484746a5f416b7902df2ac718a3fdeab
The approach taken is to implement the metafunction by specialization as usual,
and then wrap it into an alias template. This avoids having to write "typename"
and "::Type" at the use site.
MozReview-Commit-ID: VLOxb4Gu0z
--HG--
extra : rebase_source : 65e4c255eeb5646e351692e6d4f91d3e6c8e5789
SupportsServoStyleBackend() uses methods in nsIDocument, so it would be more
straightforward to do that in UpdateStyleBackendType().
Also, call StyloEnabled() before doing other logic so that the warning about
"no docshell" won't show up when stylo is built but disabled.
MozReview-Commit-ID: 9ZUYatPBv1r
--HG--
extra : rebase_source : ea130cdf2ef0b49d73bd688aeca1fc227431441c
In this way, the callers who have nsIDocument don't need to cast to nsDocument.
MozReview-Commit-ID: 8zVUjkbrlaG
--HG--
extra : rebase_source : c444a103a430e3746508cc894902e677d58e65fe
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
It is possible that events created before the OS goes to sleep will remain
unhandled until after the OS wakes. They will have long response times on
platforms where TimeStamp increments during sleep (like Windows) even though
they really shouldn't. (and the user likely doesn't care if they do).
So don't record those.
MozReview-Commit-ID: 4ybjF8gjkae
--HG--
extra : rebase_source : ff48923c6589d9cbac3284dd81f28598677ca449
This is because it does ensure both, and some of the callers care about
size and some care about position.
MozReview-Commit-ID: 3e8II6Lf72X
--HG--
extra : transplant_source : %EE%5E%87%1D%AA%EB%B9%22%D9%D6%D2%9D6U%C4%2A%CA%A1r%E9
The nsBidi API requires the consumer to first call SetPara()
in order to perform bidi resolution and that resets the data
members, so there is no need to recreate nsBidi objects from
scratch each time we need to perform bidi resolution.
Having this API allows us to reuse this object across the
calls to nsBidiPresUtils members.