gecko-dev/layout/style/nsStyleStructInlines.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

211 строки
8.1 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
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::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();
}
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);
}
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
bool nsStyleDisplay::IsFixedPosContainingBlockForNonSVGTextFrames(
const 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.StyleDisplay() == this, "unexpected aStyle");
if (mWillChange.bits & mozilla::StyleWillChangeBits::FIXPOS_CB) {
return true;
}
return aStyle.StyleEffects()->HasFilters() ||
aStyle.StyleEffects()->HasBackdropFilters();
}
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();
}
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
bool 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->StyleDisplay() == 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;
}
if (nsSVGUtils::IsInSVGTextSubtree(aContextFrame)) {
return false;
}
MOZ_ASSERT(IsAbsPosContainingBlock(aContextFrame),
"Any fixed-pos CB should also be an abs-pos CB");
return true;
}
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
bool 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() ||
(mWillChange.bits & mozilla::StyleWillChangeBits::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->StyleDisplay() == 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::IsStickyPositioned(const nsIFrame* aContextFrame) const {
NS_ASSERTION(aContextFrame->StyleDisplay() == this,
"unexpected aContextFrame");
return IsStickyPositionedStyle() &&
!nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
bool nsStyleDisplay::IsAbsolutelyPositioned(
const nsIFrame* aContextFrame) const {
NS_ASSERTION(aContextFrame->StyleDisplay() == this,
"unexpected aContextFrame");
return IsAbsolutelyPositionedStyle() &&
!nsSVGUtils::IsInSVGTextSubtree(aContextFrame);
}
mozilla::StylePointerEvents nsStyleUI::GetEffectivePointerEvents(
nsIFrame* aFrame) const {
if (aFrame->GetContent() && !aFrame->GetContent()->GetParent()) {
// The root frame is not allowed to have pointer-events: none, or else
// no frames could be hit test against and scrolling the viewport would
// not work.
return mozilla::StylePointerEvents::Auto;
}
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.IsNone() &&
layer.mAttachment == mozilla::StyleImageLayerAttachment::Local) {
return true;
}
}
return false;
}
#endif /* !defined(nsStyleStructInlines_h_) */