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
Currently, if an event is consumed in the main process, EventStateManager
does not send it to remote process. However, this is unexpected behavior
for some WidgetKeyboardEvent dispatchers. OS sometimes has consumed native
key events before sending applications. For example, Alt key on Windows
should activate menu bar of focused window but Alt key may be consumed before
focused window receives the event. In such case, we mark Alt keyboard event
as "consumed before dispatch", and chrome treat it like as its preventDefault()
is called in web content. (Note that for compatibility with other browsers,
the consumed state is not exposed to web content. So, Event.defaultPrevented
returns false in web content.)
Therefore, we need to treat "consumed" state and "cross process forwarding"
state separately. This patch makes calling WidgetEvent::PreventDefault()
always stops cross process forwarding for backward compatibility. Additionally,
for the special case mentioned above, this patch makes
WidgetEvent::PreventDefaultBeforeDispatch() take additional argument,
|aIfStopCrossProcessForwarding|. If this is CrossProcessForwarding::eStop,
the event won't be sent to remote process as same as calling PreventDefault().
Otherwise, CrossProcessForwarding::eHold, PreventDefaultBeforeDispatch() call
does not change "cross process forwarding" state. I.e., if the event's
StopCrossProcessForwarding() and PreventDefault() are not called until
EventStateManager::PostHandleEvent(), the event will be sent to remote process
as usual.
MozReview-Commit-ID: IQGWJvXetxV
--HG--
extra : rebase_source : 4ccdd500e80b8fe29e469ac3b85578e1c07c8358
The probe is expired and there's no clear owner here so let's remove this
for now.
--HG--
extra : rebase_source : 51c332a790ce5081ce4645633991c3b9213a5d21
extra : source : 98d141e6d651b804cf35040a5c20be74b6fb6c7a
Since the test relies on missing keyframes handling.
MozReview-Commit-ID: IfbMvRhIeOh
--HG--
extra : rebase_source : 447bec6c7bc8d8a79f00bb738182e0647ee68ec5
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
This fixes a MathML-disabled reftest with the previous patch.
The reftest assumes the sheet is not loaded, so let's just do that. This
effectively preserves behavior.
MozReview-Commit-ID: KrR4pHslycz
On top of the two depending bugs.
Funny how there's a comment referencing bug 77999.
Differential Revision: https://phabricator.services.mozilla.com/D1750
MozReview-Commit-ID: LCuJROu92bo
Continuations do not have placeholders. There's a bunch of code that already
deals with that in other places in the tree.
MozReview-Commit-ID: Htizql7692e
This fixes a MathML-disabled reftest with the previous patch.
The reftest assumes the sheet is not loaded, so let's just do that. This
effectively preserves behavior.
MozReview-Commit-ID: KrR4pHslycz
On top of the two depending bugs.
Funny how there's a comment referencing bug 77999.
Differential Revision: https://phabricator.services.mozilla.com/D1750
MozReview-Commit-ID: LCuJROu92bo
When an animation targets a CSS property that could cause a containing block to
be generated for its descendants, this containing block must be generated even
if the particular property values used by the animation would not normally
trigger generation of a containing block (e.g. transform: none). This is due
to the implicit application of will-change defined in CSS Animations[1] and Web
Animations[2].
Since this containing block is generated at the start of the animations, we can
throttle animations that produce the UpdateContainingBlock change hint for
animations that are not visible since they shouldn't have any further side
effects beyond the generation of containing blocks (which have already happened).
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Unfortunately perspective animations starting with 'none' and transform
animations from 'none' to 'none' don't create a containing block (bug 1470349
and bug 1470370). That doesn't block the optimization in this patch, however,
since those bugs occur regardless of element visibility.
MozReview-Commit-ID: 8rTl8dShHrD
--HG--
extra : rebase_source : 886b003d0f3c555a12baf0de81b4130ef2d71e82
In the case where the target element is scrolled out or visibility:hidden and
has no visible descendants, we can treat nsChangeHint_UpdateOverflow just like
transform animations which produce nsChangeHint_UpdatePostTransformOverflow,
i.e. unthrottle the animations periodically if the target element is inside a
scrollable element. Some transform animations produce UpdateOverflow hint,
so it would be really nice to optimize the hint.
MozReview-Commit-ID: E1MgPZRi8mW
--HG--
extra : rebase_source : d29a29e137742f88a64b3b18a5a7d4e64e76f54f
This was a memory-saving optimization introduced as part of dependencies for bug
686875, but a more general system landed in bug 77999 for Gecko and
https://github.com/servo/servo/pull/18509 for Servo.
So now it's probably even a bit of a pessimization (though probably not huge),
and given this causes bugs like bug 1462742, bug 1157592, and bug 1468145, and
fishiness like the one pointed out in this bug, we may as well remove it.
The performance impact of having to lookup through more rules should be minimal
given the bloom filter and the rule hash optimizations.
This makes me wonder whether we could remove the whole concept of on-demand UA
sheets, since they've caused pain, for example, when the frontend people try
loading <svg>s from NAC (since that triggers sheet loading from frame
construction, which is not good). I'm not concerned about loading mathml.css and
svg.css everywhere, though xul.css may not be as doable since it adds a bunch of
attribute-dependent selectors. Though on the other hand I asserted in the
xul.css code and we don't load it in content with <video> / <input
type="date/time/etc"> and such, afaict, so maybe now that legacy addons are gone
we can remove that sheet from content processes altogether.
MozReview-Commit-ID: 9JCWNZj6BkT
Those changesets which are related to animations introduced in bug 1462497
seems to cause new crashes. I think the first two changesets for the bug fixed
the original crash cases but the last two (i.e. these changesets) introduced
other crashes unfortunately.
MozReview-Commit-ID: 9LD2hIIXA2y
--HG--
extra : rebase_source : 102c5532128039dcf8274c214e17d58d9a1aa483
This commit just adds some #include directives and "using namespace" directives.
(The "using namespace mozilla::dom;" are the important namespace directives
here, though I've included "using namespace mozilla;" alongside it as well, for
completeness/consistency.)
Differential Revision: https://phabricator.services.mozilla.com/D1647
Just avoid crashing if the element has no data, treat is as display: none.
TakeChangeHint already returns wasRestyled = false, so we won't end up trying to
reconstruct anything, and we don't set frame construction flags in
nsCSSFrameConstructor so we won't traverse children either.
MozReview-Commit-ID: 2gXmHSlj3Jw
--HG--
extra : rebase_source : 9d95a4f3ee8fabc4d73a39699c677ba184061370
- Fix the implementation to return a numerically correct result
- Change call sites that should have instead been using
CalculateCompositedSizeInCssPixels(), to do so
- Rename and document to emphasize that the returned rect is in the
CSS pixels of the content surrounding the scroll frame
MozReview-Commit-ID: GCPbA1k88rz
--HG--
extra : rebase_source : f5b937936fb84b3ae414d6cf0250add4078a9d53
