gecko-dev/layout/style/nsStyleStructInlines.h

278 строки
8.9 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
/*
* Inline methods that belong in nsStyleStruct.h, except that they
* require more headers.
*/
#ifndef nsStyleStructInlines_h_
#define nsStyleStructInlines_h_
#include "nsIFrame.h"
#include "nsStyleStruct.h"
#include "nsIContent.h" // for GetParent()
#include "nsTextFrame.h" // for nsTextFrame::ShouldSuppressLineBreak
#include "nsSVGUtils.h" // for nsSVGUtils::IsInSVGTextSubtree
inline void
nsStyleImage::EnsureCachedBIData() const
{
if (!mCachedBIData) {
const_cast<nsStyleImage*>(this)->mCachedBIData =
mozilla::MakeUnique<CachedBorderImageData>();
}
}
inline void
nsStyleImage::SetSubImage(uint8_t aIndex, imgIContainer* aSubImage) const
{
EnsureCachedBIData();
mCachedBIData->SetSubImage(aIndex, aSubImage);
}
inline imgIContainer*
nsStyleImage::GetSubImage(uint8_t aIndex) const
{
return (mCachedBIData) ? mCachedBIData->GetSubImage(aIndex) : nullptr;
}
bool
nsStyleText::HasTextShadow() const
{
return mTextShadow;
}
nsCSSShadowArray*
nsStyleText::GetTextShadow() const
{
return mTextShadow;
}
bool
nsStyleText::NewlineIsSignificant(const nsTextFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleText() == this, "unexpected aContextFrame");
return NewlineIsSignificantStyle() &&
!aContextFrame->ShouldSuppressLineBreak() &&
!aContextFrame->Style()->IsTextCombined();
}
bool
nsStyleText::WhiteSpaceCanWrap(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleText() == this, "unexpected aContextFrame");
return WhiteSpaceCanWrapStyle() &&
!nsSVGUtils::IsInSVGTextSubtree(aContextFrame) &&
!aContextFrame->Style()->IsTextCombined();
}
bool
nsStyleText::WordCanWrap(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleText() == this, "unexpected aContextFrame");
return WordCanWrapStyle() && !nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
bool
nsStyleDisplay::IsBlockInside(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
if (nsSVGUtils::IsInSVGTextSubtree(aContextFrame)) {
return aContextFrame->IsBlockFrame();
}
return IsBlockInsideStyle();
}
bool
nsStyleDisplay::IsBlockOutside(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
if (nsSVGUtils::IsInSVGTextSubtree(aContextFrame)) {
return aContextFrame->IsBlockFrame();
}
return IsBlockOutsideStyle();
}
bool
nsStyleDisplay::IsInlineOutside(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
if (nsSVGUtils::IsInSVGTextSubtree(aContextFrame)) {
return !aContextFrame->IsBlockFrame();
}
return IsInlineOutsideStyle();
}
bool
nsStyleDisplay::IsOriginalDisplayInlineOutside(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
if (nsSVGUtils::IsInSVGTextSubtree(aContextFrame)) {
return !aContextFrame->IsBlockFrame();
}
return IsOriginalDisplayInlineOutsideStyle();
}
mozilla::StyleDisplay
nsStyleDisplay::GetDisplay(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
if (nsSVGUtils::IsInSVGTextSubtree(aContextFrame) &&
mDisplay != mozilla::StyleDisplay::None) {
return aContextFrame->IsBlockFrame() ? mozilla::StyleDisplay::Block
: mozilla::StyleDisplay::Inline;
}
return mDisplay;
}
bool
nsStyleDisplay::IsFloating(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
return IsFloatingStyle() && !nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
// If you change this function, also change the corresponding block in
// nsCSSFrameConstructor::ConstructFrameFromItemInternal that references
// this function in comments.
bool
nsStyleDisplay::HasTransform(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
return HasTransformStyle() && aContextFrame->IsFrameOfType(nsIFrame::eSupportsCSSTransforms);
}
bool
nsStyleDisplay::HasPerspective(const nsIFrame* aContextFrame) const
{
MOZ_ASSERT(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
return HasPerspectiveStyle() && aContextFrame->IsFrameOfType(nsIFrame::eSupportsCSSTransforms);
}
bool
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
nsStyleDisplay::IsFixedPosContainingBlockForNonSVGTextFrames(
mozilla::ComputedStyle& aStyle) const
{
// NOTE: Any CSS properties that influence the output of this function
// should have the FIXPOS_CB flag set on them.
NS_ASSERTION(aStyle.ThreadsafeStyleDisplay() == this, "unexpected aStyle");
if (mWillChangeBitField & NS_STYLE_WILL_CHANGE_FIXPOS_CB) {
return true;
}
return aStyle.ThreadsafeStyleEffects()->HasFilters();
}
bool
nsStyleDisplay::IsFixedPosContainingBlockForContainLayoutAndPaintSupportingFrames() const
{
Bug 1472919 - Establish stacking context, containing block, independent formatting context for contain:layout. r=dbaron MozReview-Commit-ID: H36HpePX29C --HG-- rename : layout/reftests/w3c-css/submitted/contain/contain-paint-containing-block-absolute-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-containing-block-absolute-001.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-containing-block-fixed-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-containing-block-fixed-001.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-formatting-context-float-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-formatting-context-float-001.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-formatting-context-margin-001-ref.html => layout/reftests/w3c-css/submitted/contain/contain-layout-formatting-context-margin-001-ref.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-formatting-context-margin-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-formatting-context-margin-001.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-ignored-cases-no-principal-box-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-ignored-cases-no-principal-box-001.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-containing-block-absolute-001-ref.html => layout/reftests/w3c-css/submitted/contain/contain-layout-ignored-cases-no-principal-box-002-ref.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-containing-block-absolute-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-ignored-cases-no-principal-box-002.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-containing-block-fixed-001-ref.html => layout/reftests/w3c-css/submitted/contain/contain-layout-ignored-cases-no-principal-box-003-ref.html rename : layout/reftests/w3c-css/submitted/contain/contain-paint-containing-block-fixed-001.html => layout/reftests/w3c-css/submitted/contain/contain-layout-ignored-cases-no-principal-box-003.html extra : rebase_source : d6e53cd496c98949b0b4ecfb96d6a8a5eb4d6635
2018-07-20 20:57:22 +03:00
return IsContainPaint() || IsContainLayout();
}
bool
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
nsStyleDisplay::IsFixedPosContainingBlockForTransformSupportingFrames() const
{
// NOTE: Any CSS properties that influence the output of this function
// should have the FIXPOS_CB flag set on them.
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
return HasTransformStyle() || HasPerspectiveStyle();
}
bool
nsStyleDisplay::IsFixedPosContainingBlock(const nsIFrame* aContextFrame) const
{
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
mozilla::ComputedStyle* style = aContextFrame->Style();
NS_ASSERTION(style->ThreadsafeStyleDisplay() == this,
"unexpected aContextFrame");
// NOTE: Any CSS properties that influence the output of this function
// should have the FIXPOS_CB flag set on them.
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
if (!IsFixedPosContainingBlockForNonSVGTextFrames(*style) &&
(!IsFixedPosContainingBlockForContainLayoutAndPaintSupportingFrames() ||
!aContextFrame->IsFrameOfType(nsIFrame::eSupportsContainLayoutAndPaint)) &&
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
(!IsFixedPosContainingBlockForTransformSupportingFrames() ||
!aContextFrame->IsFrameOfType(nsIFrame::eSupportsCSSTransforms))) {
return false;
}
return !nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
bool
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
nsStyleDisplay::IsAbsPosContainingBlockForNonSVGTextFrames() const
{
// NOTE: Any CSS properties that influence the output of this function
// should have the ABSPOS_CB set on them.
return IsAbsolutelyPositionedStyle() ||
IsRelativelyPositionedStyle() ||
(mWillChangeBitField & NS_STYLE_WILL_CHANGE_ABSPOS_CB);
}
bool
nsStyleDisplay::IsAbsPosContainingBlock(const nsIFrame* aContextFrame) const
{
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
mozilla::ComputedStyle *style = aContextFrame->Style();
NS_ASSERTION(style->ThreadsafeStyleDisplay() == this,
"unexpected aContextFrame");
// NOTE: Any CSS properties that influence the output of this function
// should have the ABSPOS_CB set on them.
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
if (!IsAbsPosContainingBlockForNonSVGTextFrames() &&
!IsFixedPosContainingBlockForNonSVGTextFrames(*style) &&
(!IsFixedPosContainingBlockForContainLayoutAndPaintSupportingFrames() ||
!aContextFrame->IsFrameOfType(nsIFrame::eSupportsContainLayoutAndPaint)) &&
Bug 1479859 patch 2 - Send nsChangeHint_UpdateContainingBlock when containing block-ness changes due to one property change, while another property that might trigger containing block-ness doesn't do so because of the frame type. r=emilio This fixes a rather subtle bug. What the underlying code here is trying to do is remove nsChangeHint_UpdateContainingBlock when some properties that influence whether a frame is a containing block for absolutely positioned or fixed positioned elements have changed, but the final calculation of being a containing block has not changed. However, the old code was using a function that tested whether the style could *possibly* lead to a frame being a containing block. Some of the properties (like the transform properties) that lead to being a containing block, for example, don't apply to non-replaced inlines. Some, however, do (such as 'filter'). So if there's a dynamic change adding or removing a filter, on an inline that also has an *ignored* transform property (like 'transform' or 'perspective') set, then the code prior to this patch causes us to remove the UpdateContainingBlock hint. This patch fixes things by testing whether being a containing block could have changed for *any* type of frame, by separately testing the changes. The added tests fail without the patch and pass with the patch, viewed in isolation. However, without the previous patch, test 003 passes. Test 003 also fails in Chrome (but 001 and 002 pass). Differential Revision: https://phabricator.services.mozilla.com/D2814 --HG-- extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
2018-08-08 01:02:07 +03:00
(!IsFixedPosContainingBlockForTransformSupportingFrames() ||
!aContextFrame->IsFrameOfType(nsIFrame::eSupportsCSSTransforms))) {
return false;
}
return !nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
bool
nsStyleDisplay::IsRelativelyPositioned(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
return IsRelativelyPositionedStyle() &&
!nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
bool
nsStyleDisplay::IsAbsolutelyPositioned(const nsIFrame* aContextFrame) const
{
NS_ASSERTION(aContextFrame->StyleDisplay() == this, "unexpected aContextFrame");
return IsAbsolutelyPositionedStyle() &&
!nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
uint8_t
nsStyleUserInterface::GetEffectivePointerEvents(nsIFrame* aFrame) const
{
if (aFrame->GetContent() && !aFrame->GetContent()->GetParent()) {
// The root element has a cluster of frames associated with it
// (root scroll frame, canvas frame, the actual primary frame). Make
// those take their pointer-events value from the root element's primary
// frame.
nsIFrame* f = aFrame->GetContent()->GetPrimaryFrame();
if (f) {
return f->StyleUserInterface()->mPointerEvents;
}
}
return mPointerEvents;
}
bool
nsStyleBackground::HasLocalBackground() const
{
NS_FOR_VISIBLE_IMAGE_LAYERS_BACK_TO_FRONT(i, mImage) {
const nsStyleImageLayers::Layer& layer = mImage.mLayers[i];
if (!layer.mImage.IsEmpty() &&
layer.mAttachment == mozilla::StyleImageLayerAttachment::Local) {
return true;
}
}
return false;
}
#endif /* !defined(nsStyleStructInlines_h_) */