According to roc the content viewer position doesn't mean much; only the size is
set to anything meaningful. Therefore using the position from the content viewer
bounds is not a good idea, and we should use the position from the frame bounds
instead. This patch also changes GetContentViewerBounds to GetContentViewerSize
so that it's harder to accidentally use the position in other places.
This code is no longer needed because tiling is enabled on all
scrollable layers on B2G, and so we only draw tile-sized chunks
of the displayport. Therefore the textures created will never
exceed the max texture size. On non-B2G platforms this code is
not used anyway so there is no effect. Going forward we should
always be enabling tiling before enabling APZ on new platforms
so it is unlikely that we will need this code.
This is an additional bit on nsRestyleHint that says that the restyling
operation should also perform all the work needed to switch between
style-without-animation and style-with-animation (based on
nsPresContext::IsProcessingAnimationStyleChange). These concepts will
go away in bug 960465.
Note that we don't want this behavior for the animation-only style
update code (bug 996796, etc.), and I wanted to make this explicit so
that it was clear when it was happening, and so that it was clear what
code should be removed when we git rid of it.
This is the workaround needed to land bug 977991 prior to bug 960465.
(I think there's also a minor dependency in the other direction, so we
need a workaround one way or the other.)
Note that this depends on bug 1057231.
This is needed because patch 1 and patch 3 did not add a mechanism that
allows restyling pseudo-elements, which would be substantially more work
and very little use (since the only case in which they have style
attributes is for our internal use on the ::-moz-color-swatch
pseudo-element).
RestyleUndisplayedChildren does not need the same fix because it's only
used on elements, and never on pseudo-elements or anonymous boxes.
This allows posting a restyle that says that only the rule(s) from the
StyleAttrSheet cascade level will be replaced, which avoids running
selector matching.
Part 4 will ensure that we only invoke this code for element styles (and
not pseudo-element or anonymous box styles). Despite that, I prefer
having the runtime check here as well given that it's a very simple way
to ensure we don't do something silly that might have security
implications.
This allows nsStyleSet::RuleNodeWithReplacement to call it without
constructing an entire (and unnecessary) ElementRuleProcessorData, which
will happen in patch 3.
This avoids having to cast back to nsRestyleHint after using bitwise
operators, and allows |= (etc.).
(In the future we should consider converting nsRestyleHint, and probably
also nsChangeHint, to use MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS.)
This allows posting a restyle that says that only the rule(s) from the
SVGAttrAnimationSheet cascade level will be replaced, which avoids running
selector matching.
This is needed to land bug 977991 prior to landing bug 960465, since
that requires replacing all levels that contain animations.
(I'll rename this to match the name determined in bug 1057231.)
This allows nsStyleSet::RuleNodeWithReplacement to call it without
constructing an entire (and unnecessary) ElementRuleProcessorData, which
will happen in patch 2.
This is only a very slight reordering of their position in the cascade,
since they were previously walked at the end of
nsSVGElement::WalkContentStyleRules, which was called near the end of
nsHTMLStyleSheet::RulesMatching. So the only change should be that they
now take priority over the xml:lang rule added by nsHTMLStyleSheet, a
rule with which they do not interact.
I will fix the indentation of gCascadeLevels in bug 977991 patch 2,
which adds a member to each element of the array.
Note that this bumps the maximum sheetType from 8 to 9 (and number of
them from 9 to 10), which does not require updating
NS_RULE_NODE_LEVEL_MASK, since NS_RULE_NODE_LEVEL_MASK currently has 4
bits and allows a maximum of 15.
This patch series (to move SVG Animation rules to their own level of the
cascade) is needed so that they can participate in the mechanism for
updating only animation styles to the present time without touching any
other styles.
In theory, this should have been done as part of 996796 or even as part
of prior work on off main thread animations, except that it doesn't seem
possible to have SVG Animations and CSS Transitions interacting on the
same element and have that element's style out of date, which means it
wasn't necessary for the existing code to update only animation styles.
However, bug 960465 will use this similar mechanism as the new mechanism
for making sure transitions start in a reasonable way (replacing the
mechanism of phases, going from style without animation to style with
animation via nsPresContext::IsProcessingAnimationStyleChange). This
will require that, for SVG Animations to continue interacting correctly
with CSS Transitions, that they have their own cascade level so that
they can participate in RestyleManager::UpdateOnlyAnimationStyles.
Additionally, this is needed even sooner, for bug 977991, which needs
(temporarily, until bug 960465 lands) a mechanism for updating the style
attribute style *and* all animation-phase-dependent styles.
Yes, it's a little bit annoying to have to have another class, and
another object per-document for this, but that's currently what comes
with being a level of the cascade. But it's one class and one object
per document, and I believe there will be substantial benefits to having
all rule processor levels be only-animation-related or
not-animation-related (except for the style attribute level, which is
simple enough that it isn't needed yet).
This is fine since the assertion is just checking that we're not calling
RuleNodeWithReplacement in cases when stronger restyling (i.e.,
restyling that does more work) is needed; the new eRestyle_Force and
eRestyle_ForceDescendants flags control whether we restyle at all.
This probably should have been done in bug 931668 (since bug 996796
landed before bug 931668, although not before the patches were written),
but it doesn't actually show up in our test suite until bug 977991 (or
maybe slightly earlier in bug 1057231 or bug 1058346).
