Bug 1187851 patch 3 - Rename nsChangeHint_AddOrRemoveTransform to nsChangeHint_UpdateContainingBlock. r=roc

This is because patch 4 now uses AddAndRemoveTransform hints for changes
that are other than adding and removing a transform.  There's still a
little bit of transform-related stuff there too (which I did make
conditional in patch 2).
This commit is contained in:
L. David Baron 2015-08-03 20:18:00 -07:00
parent 3266ba066f
commit 86c6ca5045
4 changed files with 8 additions and 8 deletions

View File

@ -759,7 +759,7 @@ RestyleManager::ProcessRestyledFrames(nsStyleChangeList& aChangeList)
}
}
if ((hint & nsChangeHint_AddOrRemoveTransform) && frame &&
if ((hint & nsChangeHint_UpdateContainingBlock) && frame &&
!(hint & nsChangeHint_ReconstructFrame)) {
if (NeedToReframeForAddingOrRemovingTransform(frame) ||
frame->GetType() == nsGkAtoms::fieldSetFrame ||
@ -773,7 +773,7 @@ RestyleManager::ProcessRestyledFrames(nsStyleChangeList& aChangeList)
// Normally frame construction would set state bits as needed,
// but we're not going to reconstruct the frame so we need to set them.
// It's because we need to set this state on each affected frame
// that we can't coalesce nsChangeHint_AddOrRemoveTransform hints up
// that we can't coalesce nsChangeHint_UpdateContainingBlock hints up
// to ancestors (i.e. it can't be an inherited change hint).
if (cont->IsAbsPosContaininingBlock()) {
if (cont->StyleDisplay()->HasTransform(cont)) {
@ -2631,7 +2631,7 @@ ElementRestyler::AddLayerChangesForAnimation()
// If we have a transform layer but don't have any transform style, we
// probably just removed the transform but haven't destroyed the layer
// yet. In this case we will add the appropriate change hint
// (nsChangeHint_AddOrRemoveTransform) when we compare style contexts
// (nsChangeHint_UpdateContainingBlock) when we compare style contexts
// so we can skip adding any change hint here. (If we *were* to add
// nsChangeHint_UpdateTransformLayer, ApplyRenderingChangeToTree would
// complain that we're updating a transform layer without a transform).

View File

@ -126,7 +126,7 @@ enum nsChangeHint {
* has changed whether the frame is a container for fixed-pos or abs-pos
* elements, but reframing is otherwise not needed.
*/
nsChangeHint_AddOrRemoveTransform = 0x20000,
nsChangeHint_UpdateContainingBlock = 0x20000,
/**
* This change hint has *no* change handling behavior. However, it
@ -284,7 +284,7 @@ inline nsChangeHint operator^=(nsChangeHint& aLeft, nsChangeHint aRight)
nsChangeHint_UpdateParentOverflow | \
nsChangeHint_ChildrenOnlyTransform | \
nsChangeHint_RecomputePosition | \
nsChangeHint_AddOrRemoveTransform | \
nsChangeHint_UpdateContainingBlock | \
nsChangeHint_BorderStyleNoneChange | \
nsChangeHint_NeedReflow | \
nsChangeHint_ReflowChangesSizeOrPosition | \
@ -302,7 +302,7 @@ inline nsChangeHint NS_HintsNotHandledForDescendantsIn(nsChangeHint aChangeHint)
nsChangeHint_UpdateParentOverflow |
nsChangeHint_ChildrenOnlyTransform |
nsChangeHint_RecomputePosition |
nsChangeHint_AddOrRemoveTransform |
nsChangeHint_UpdateContainingBlock |
nsChangeHint_BorderStyleNoneChange |
nsChangeHint_UpdateComputedBSize));

View File

@ -2803,7 +2803,7 @@ nsChangeHint nsStyleDisplay::CalcDifference(const nsStyleDisplay& aOther) const
// We do not need to apply nsChangeHint_UpdateTransformLayer since
// nsChangeHint_RepaintFrame will forcibly invalidate the frame area and
// ensure layers are rebuilt (or removed).
NS_UpdateHint(hint, NS_CombineHint(nsChangeHint_AddOrRemoveTransform,
NS_UpdateHint(hint, NS_CombineHint(nsChangeHint_UpdateContainingBlock,
NS_CombineHint(nsChangeHint_UpdateOverflow,
nsChangeHint_RepaintFrame)));
} else {

View File

@ -2065,7 +2065,7 @@ struct nsStyleDisplay {
nsChangeHint_UpdateTransformLayer |
nsChangeHint_UpdateOverflow |
nsChangeHint_UpdatePostTransformOverflow |
nsChangeHint_AddOrRemoveTransform |
nsChangeHint_UpdateContainingBlock |
nsChangeHint_NeutralChange);
}
static nsChangeHint DifferenceAlwaysHandledForDescendants() {