[LayoutNG] Bugfix: ScrollableOverflow for PhysicalLineBoxFragment
Part 1: PhysicalLineFragment ScrollableOverflow ScrollableOverflow was not taking relative position into account. PhyiscalLineFragment used to recompute overflow when created. This can't be done if relative position is needed, because resolving % relative position needs size of containing block. New code computes ScrollbleOverflow dynamically for PhysicalLineFragment. Part 2: Make RelativeUtils API physical. It is a better fit for PhysicalFragments. Part 3: NGMixin::AddScrollableOverflow should also add overflow from oof children. Another tricky bug: If ContainingBlock() is inline, Legacy positions OOF block wrt inline block, while NG positions OOF block wrt inline's block container. Because OOF blocks affect scrollable overflow, NG must be responsible for making sure OOF block is included in container's overflow. This patch makes 3 tests pass, and 1 new test fail: compositing/culling/tile-occlusion-boundaries.html The failure is caused by NG not using transfroms for scrollable overflow computation. To fix this, we must make fragments tranform-aware. Filed a bug to do so. Bug: 728378 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: Ib511a95cc71648e806d0cc1376f1f6303152ecee Reviewed-on: https://chromium-review.googlesource.com/1113030 Commit-Queue: Aleks Totic <atotic@chromium.org> Reviewed-by:Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#570171}
Showing
Please register or sign in to comment