44ddf0ef3d
I found this problem because I was debugging the failure of layout/reftests/w3c-css/received/css-writing-modes-3/clearance-calculations-vrl-008.xht with my patch for bug 1308876. It was failing because the red reference box that was intended to be covered up was being mispositioned leftwards by the width of the scrollbar, since we were not reflowing it when we decided that the viewport did not need scrollbars. This patch fixes that failure. This led me to this bug, where nsAbsoluteContainingBlock::FrameDependsOnContainer was incorrectly testing conditions for when the values of 'top', 'right', 'bottom', and 'left' require reflow due to changes in the size of the containing block. The old code is incorrect in a number of cases, such as: 1. in RTL, with 'right: 100px', it will say that the frame does not depend on its container's width since 'right' (offset-inline-start) is a fixed offset and 'left' is 'auto'. However, since the positioning is relative to the right edge, a change in container size does require that the absolutely positioned element be repositioned relative to the container's left edge. 2. In vertical-rl, again with 'right: 100px', it will make the same mistake, since 'right' (now offset-block-start) is a fixed offset. This is the case from the test I was debugging. 3. In vertical-rl with rtl direction and 'bottom: 100px', we will make the same mistake because 'bottom' (inline-start) is fixed and 'top' is 'auto', and we use 'bottom' rather than 'top'. However, in cases (1) and (3) we actually avoid hitting the bug in these simple-ish cases because ReflowInput::ShouldReflowAllKids() returns true whenever IsIResize() is true, which means that nsAbsoluteContainingBlock::Reflow doesn't even call FrameDependsOnContainer. However, FrameDependsOnContainer should still do the right thing because it's needed for nsAbsoluteContainingBlock::MarkSizeDependentFramesDirty, which is only used (from nsBlockFrame) when we reflow again for clearance or for interruptible reflow. I haven't attempted to write a testcase for that because it seems likely to require spending hours in the debugger trying to trigger the right code. This means that the only test that fails prior to the patch is dynamic-offset-vrl-001.html, which exercises case (2), and also happens to be the most similar to problem in clearance-calculations-vrl-008.xht. This patch also makes the tests stricter so that we do optimize away resizes in some cases where we're able to do so, such as 'left: 100px; right: auto' in RTL. (Or, rather, we would if it weren't for the IsIResize() in ShouldReflowAllKids().) MozReview-Commit-ID: 8xm1AHC21oh
52 lines
1.2 KiB
HTML
52 lines
1.2 KiB
HTML
<!DOCTYPE HTML>
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<title>CSS Test: dynamic changes to offset properties</title>
|
|
<link rel="author" title="L. David Baron" href="https://dbaron.org/">
|
|
<link rel="author" title="Mozilla" href="https://www.mozilla.org/">
|
|
<link rel="help" href="https://drafts.csswg.org/css-writing-modes-3/#vertical-layout">
|
|
<link rel="match" href="dynamic-offset-rtl-001-ref.html">
|
|
<meta name="flags" content="dom">
|
|
<meta name="assert" content="Layout rules for 'right' and 'left' are handled correctly for absolutely positioned elements, in the presence of dynamic changes to 'width' of the containing block.">
|
|
<style>
|
|
|
|
html {
|
|
writing-mode: vertical-rl;
|
|
overflow: hidden;
|
|
}
|
|
|
|
#container {
|
|
position: absolute;
|
|
top: 0;
|
|
left: 0;
|
|
width: 200px;
|
|
height: 100px;
|
|
background: yellow;
|
|
}
|
|
|
|
#abspos {
|
|
position: absolute;
|
|
top: 10px;
|
|
right: 20px;
|
|
left: 10px; /* ignored */
|
|
width: 10px;
|
|
height: 10px;
|
|
background: fuchsia;
|
|
}
|
|
|
|
</style>
|
|
|
|
<div id="container">
|
|
<div id="abspos"></div>
|
|
</div>
|
|
|
|
<script>
|
|
|
|
window.addEventListener("load", function(event) {
|
|
var e = document.getElementById("abspos");
|
|
e.offsetTop; // flush layout
|
|
e.parentNode.style.width = "100px";
|
|
});
|
|
|
|
</script>
|