In nsFrame::ComputeSize and nsFrame::ComputeSizeWithIntrinsicDimensions, the
following expressions
isFlexItem && usingFlexBasisForISize
isFlexItem && !usingFlexBasisForISize
are sometimes compiled by recent gcc/clang in the opposite order, viz
[!]usingFlexBasisForISize && isFlexItem. In this case the transformation is
correct as can be seen by analysing code earlier in these functions.
Unfortunately this causes Valgrind/Memcheck to report a branch on undefined
data which, in this case, is a false positive.
A simple fix is simply to initialise usingFlexBasisForISize to false at its
declaration point.
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
We do this by tracking them as a property on the root frame the same way we do for modified frames.
We also set the property in ProcessFrame but that is okay because we are guaranteed to finish the partial update at that point.
