1951486 - WPT testcase css-break/flexbox/single-line-row-flex-fragmentation-031.html flips between two states when zoomed

Status: NEW

(Core :: Layout, defect)

Description

[Jonathan Kew [:jfkthame]]

The testcase css-break/flexbox/single-line-row-flex-fragmentation-031.html has an unstable rendering that flip-flops between two states on successive reflows.

STR:

• load http://wpt.live/css/css-break/flexbox/single-line-row-flex-fragmentation-031.html
• observe the expected rendering (just a green square below the descriptive text)
• press Cmd-+ (or Ctrl-+) to zoom
• observe the rendering change to expose a red (error) square, with the green square moved left and up such that it is largely out of view
• press Cmd-+ / Ctrl-+ to zoom again
• observe that the rendering corrects itself
• repeat, and observe how the rendering toggles between good/bad states each time

This is related to the presence of writing-mode: vertical-rl, but the testcase also involves columns, flexbox, and absolute positioning, and it's not immediately clear exactly what the problematic combination is.

The "bad" rendering is similar to bug 1310551 and related bugs, but in this case triggering a reflow (by zooming) updates the state, but unlike the typical examples of bug 1310551, the state does not stabilize at the correct rendering after a second reflow, but keeps flip-flopping on each new reflow.

I'm linking this to the interop-2025-writingmodes metabug (even though this particular test is not included in the interop suite) as the interop work related to orthogonal flows will undoubtedly have effects here.

Comment 1

[Daniel Holbert [:dholbert]]

The thing that's changing here (when you zoom in) seems to be the static position of the absolutely positioned element.

If you add left:0 on the abspos element, then the layout becomes stable and it's reliably broken in Firefox (vs. working in Chrome), with the following two issues:
(a) the green div placed at the wrong y-position. (and hardcoded values like top:25px give different results in Firefox vs. Chrome)
(b) the green div placed in the background rather than the foreground (partially covered up by the red div) (though you can paper over that with z-index:1)

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: additional testcase

Here's a further testcase to help explore what's going on. In each example here, we have an outer <div> (shown with a cyan border) that sets a writing-mode for the test; within this, we have a <div> with two columns, and column-fill:auto; within that, a flex container that has position:relative (so it establishes an absolute positioning containing block); and finally, within that, a colored block with various position values.

We'd expect that the examples in each column should behave similarly, modulo the different writing modes that are applied to the outer block of each. And given that no offsets are specified for any of the inner positioned blocks, I think we'd expect them to always appear in the same place.

This is what happens in Chrome, except for the position:fixed examples, where (unlike position:absolute), it doesn't fragment the block across the two columns.

However, in Firefox the blocks with position:absolute or position:fixed are placed incorrectly, shifted from what their static position would have been. In addition, the vertical-rl version of position:absolute shows unstable positioning when zoomed (and neither of the two states it flips between looks correct, or matches the results in the other writing modes).