1765668 - containing block's border gets improperly applied as additional offset when computing static position of abspos frames in orthogonal flow

Status: VERIFIED FIXED

(Core :: Layout: Positioned, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

(Related to bug 1765664, but distinct/simpler issue; hence, spinning it off as its own bug)

STR:

1. Load attached testcase.
   (which is the same as bug 1765664's testcase but with some gray border added around the containing block, which triggers a distinct issue that I'm focusing on in this bug here)

ACTUAL RESULTS:
Each pink element is positioned as if there were some additional padding or margin pushing it leftwards, making it appear inset a bit from the blue area's top-left corner.

EXPECTED RESULTS:
No such lefwards push. There is no margin/padding between the blue area and its pink descendant.

(There are other issues with this testcase, too, but those are mostly covered by bug 1765664. I'm using this bug to focus specifically on this unexpected insetting.)

Chrome gives EXPECTED RESULTS for the issue that I'm focusing on here; they position the pink elements at the top-right edge the edge of the container's content-box, it looks like (just inside the border). (The elements all run off the right edge, which is arguably maybe a bug, but again let's leave that part for bug 1765664.)

NOTE: the spacing seems to be entirely caused by us mis-applying the blue area's gray border as an additional offset at some point. If you increase the size of that gray border (on the left or right side of the blue area), then the offset gets bigger.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 in Firefox Nightly 101

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a testcase where I've given the horizontal containing block an explicit width. This one is a bit easier to reason about & construct a reference case for, since it's easier to see where the expected correct position is by simply removing position:absolute.

(That doesn't work in 'testcase 1', since the parent of .abspos changes size if you remove position:absolute, which makes the expected-positioning change. But here in this testcase, I've given the parent a fixed size, so that that doesn't happen.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reference case 2

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: using padding on vert-cb instead (we get this one correct!)

Here's a modified testcase, for comparison, where I've changed things to use some padding instead of some border on the outermost div.

We get things correct in this case. So this demonstrates that this is specifically an issue with us mis-handling the border and only the border (either double-counting it, or forgetting to subtract it away, or something like that) on the abspos containing block, when we compute the hypothetical / static position of the abspos thing, and it's not a problem for the padding.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reference case 3

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

So this demonstrates that this is specifically an issue with us mis-handling the border and only the border (either double-counting it, or forgetting to subtract it away, or something like that) on the abspos containing block

This^ observation prompted me to look through ReflowInput::CalculateHypotheticalPosition( for border-specific stuff; and I found this:

  // The specified offsets are relative to the absolute containing block's
  // padding edge and our current values are relative to the border edge, so
  // translate.
  const LogicalMargin border = aCBReflowInput->ComputedLogicalBorder(wm);
  aHypotheticalPos.mIStart -= border.IStart(wm);
  aHypotheticalPos.mBStart -= border.BStart(wm);

https://searchfox.org/mozilla-central/rev/5204ea3d3dac5832075fb61d9689dd7879ed91b2/layout/generic/ReflowInput.cpp#1389-1394

As a hacky-experiment, I tried changing the first -= to += -- and that makes my attached testcase 1 and testcase 2 render as-expected!

So I suspect this is a case where we need to see if the corresponding writing-mode axes have the same "polarity" vs. if they disagree. (In this testcase, wm's inline-axis is LTR, whereas the corresponding axis in the abspos containing block is RTL (from vertical-rl), so that reversal presumably means we need to add offsets rather than subtract them, or something along those lines.)

Comment 7

[David Shin[:dshin]]

Attachment: Bug 1765668: Fix border offset when the `writing-mode` of an abspos element's containing block differs from its absolute containing block. r=dholbert

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2609e3d8e65d
Fix border offset when the `writing-mode` of an abspos element's containing block differs from its absolute containing block. r=dholbert

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34114 for changes under testing/web-platform/tests

Comment 10

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/2609e3d8e65d

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 12

[Hani Yacoub, Desktop QA]

Attachment: firefox vs chrome.png

I still can see differences comparing Latest Firefox Nightly or Beta with Chrome after opening testcase1.
Is this expected?

Comment 13

[David Shin[:dshin]]

Ah, that is an occurrence of bug 1769102, since explicitly adding style="width:44px; height: 20px; to that div results in behaviour matching Chrome (And I believe is more correct).

Comment 14

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04 x64.