- added overrideDPPX to nsIContentViewer
- made CSSStyleSheet and GlobalWindow using the overrideDPPX value
- added unit test with frame check
MozReview-Commit-ID: AOWpGs4vb9H
--HG--
extra : rebase_source : 45d9ae2c9b7aad835b5602e805ec7260c69c05b8
Instead of skipping the absolute and fixed child lists, we walk all kids of the
frame. But before recursing down into things that are absolute containing
blocks we ensure that we're only looking for fixed-pos placeholders, so we don't
reframe if we have a relatively positioned descendant with absolutely positioned
kids, for example. Note that this part is pure optimization attempt, and it
might be cheaper to not do it: IsAbsoluteContainingBlock is not that cheap and
the situations where we avoid reframing due to this optimization are likely
fairly rare.
Some things like nsDocumentViewer::SetPageMode recreate the presShell, so we
can't rely on the flags being correctly set always.
MozReview-Commit-ID: 4bxNjXGBaJt
--HG--
extra : rebase_source : f40ddb64d261778be2fd051503f7d2747f0c80e8
The existing code, from bug 922669, in ParsePseudoSelector that allows
things to come after a pseudo-element requires that the first character
after the pseudo-element be a colon. However, this doesn't forbid
things like ::-moz-color-swatch:hover#foo, which need to be errors in
ParseSelector; those tests are added here. Furthermore, the
error-checking in ParsePseudoSelector doesn't prevent the pseudo-element
from being followed by a :not() or by an additional pseudo-element; to
fix that this patch moves the error tests out of the pseudo-class
condition and also has it test !isPseudoClass.
Without the patch, the tests produced the following failures:
TEST-UNEXPECTED-FAIL | layout/style/test/test_selectors.html | selector ::-moz-color-swatch:not(.foo) was a parser error - got "1402", expected "auto"
TEST-UNEXPECTED-FAIL | layout/style/test/test_selectors.html | selector '::-moz-color-swatch:not(.foo)' plus EOF is parse error
followed by a crash due to:
Assertion failure: !(IsPseudoElement() && (mIDList || mAttrList)) (If pseudo-elements can have id or attribute selectors after them, specificity calculation must be updated), at /home/dbaron/builds/ssd/mozilla-central/mozilla/layout/style/StyleRule.cpp:503 in CalcWeightWithoutNegations
from the "::-moz-color-swatch:hover#foo" test.
With that test commented out (and still without the code changes), there
is instead an additional pair of failures from the following test:
TEST-UNEXPECTED-FAIL | layout/style/test/test_selectors.html | selector .foo::after:not(.bar) ~ h3 was a parser error - got "1406", expected "auto"
TEST-UNEXPECTED-FAIL | layout/style/test/test_selectors.html | selector '.foo::after:not(.bar) ~ h3' plus EOF is parse error
along with a failure due to an unexpected assertion:
###!!! ASSERTION: Shouldn't have negations: '!selector->mNegations', file /home/dbaron/builds/ssd/mozilla-central/mozilla/layout/style/nsCSSRuleProcessor.cpp, function AddRule, line 3415
With the patch, the tests pass.
MozReview-Commit-ID: KxAFSQtPVhu
Without the patch (or, rather, with the new code in nsStyleContext::CalcStyleDifferenceInternal commented out), the second of the tests added fails:
TEST-UNEXPECTED-FAIL | layout/style/test/test_change_hint_optimizations.html | adding a transform style to an element with filter: blur(3px); should not cause frame reconstruction even when the element has absolutely positioned descendants - got 34, expected 28
The first of the new tests doesn't fail without the patch because
will-change:transform influences HasTransformStyle. However, since that
case is probably the most important one, it still seems worth testing
explicitly.
With the patches, both tests pass.
MozReview-Commit-ID: 8n7QKGxd3j6
The fact that HasTransform() depends on the frame requires the *Internal
functions rather than simply having the public function that takes a
frame call the public function that takes a style context.
MozReview-Commit-ID: CcWZjDTIr52
