Firefox fails WPT css/css-multicol/multicol-span-all-rule-002.html
Categories
(Core :: Layout: Columns, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox138 | --- | fixed |
People
(Reporter: TYLin, Assigned: jfkthame)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files)
This test is part of interop-2025 Writing modes:
Based on the screenshot comparison, Firefox almost passes the test except for the scrollbar. The expected result is that no scrollbar should be present.
|
||
Comment 1•21 days ago
|
||
The scrollbar is there because the elements with column-span: all (the ones with class="span") seem to be getting sized to the height of the viewport, which makes them overflow off the bottom a bit (and generate a scrollbar). You can see its height in devtools if you hover the element, or if you add a border to it.
Probably it shouldn't be ending up that tall. In Chrome, they end up as tall as the multicol element.
|
|
||
Comment 2•21 days ago
|
||
Here's a reduced testcase. The cyan element is much too tall in Firefox, and it's what generates the scrollable overflow and causes a scrollbar to appear.
|
Reporter | |
Comment 3•21 days ago
|
||
This bug might be related to bug 1095937 or bug 1570039.
|
Assignee | |
Comment 4•20 days ago
|
||
Yeah, I'm going to revisit fantasai's (unlanded) patch in bug 1095937 to see what that can offer us, as I think it may be relevant to this example.
|
|
Assignee | |
Comment 5•8 days ago
|
||
I looked into the old patch in bug 1095937, but it doesn't actually resolve the issue here, and the approach there has some mismatch when compared to the current spec.
In particular, the strategy of recording an orthogonal-limit which starts out as the size of the ICB, and potentially reducing it for each explicitly-sized scroll container as we go down the frame tree doesn't work correctly because the spec says that only the nearest ancestor scroll container of the orthongonal flow should be considered. If it does not have an explicitly specified size, we fall back to the ICB; we should not consider other intervening scroll containers. This was the reason for the failure in css-writing-modes/available-size-010.html, noted in https://phabricator.services.mozilla.com/D45948#1524904.
I think a better approach is to dispense with the orthogonal-limit concept altogether, and instead search up the frame tree as needed when setting up the ReflowInput. This will allow us to correctly consider only the closest ancestor scroll container.
In principle this makes ReflowInput construction a bit more expensive, but the added cost applies only to orthogonal-flow children, which are relatively rare; I think this is better than doing the work to maintain the orthogonal-limit concept for every scroll container, when it will be unneeded in the vast majority of cases.
|
|
Assignee | |
Comment 6•8 days ago
|
||
The old "orthogonal limit" in ReflowInput was a rather ad hoc mechanism created
during the early implementation of writing modes, to avoid reflowing orthogonal
flows with unconstrained inline size. The spec has since been clarified to describe
the expected behavior in more detail, and we can dispense with the orthogonal-limit
concept and instead implement the constraints called for in the spec.
With this, we pass all the css-writing-modes/available-size-* tests (as well as
fixing a couple of other testcases that are dependent on this behavior).
|
||
Updated•8 days ago
|
|
||
Comment 10•7 days ago
|
||
|
||
Comment 11•7 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a9fbc4a282c9
https://hg.mozilla.org/mozilla-central/rev/0c28f0e07f74
https://hg.mozilla.org/mozilla-central/rev/f143f95c7677
https://hg.mozilla.org/mozilla-central/rev/f786cd5987c5
Description
•