Open Bug 1570039 Opened 2 years ago Updated 6 months ago

Multi-columns in orthogonal writing-mode overflow their container with column-span enabled


(Core :: Layout: Columns, defect, P3)




Tracking Status
firefox70 --- affected


(Reporter: TYLin, Assigned: TYLin)


(Blocks 1 open bug)



(4 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #1173689 +++

The patch will not help if column-span is enabled.

Also, both original test cases Testcase with column width and Testcase with column-count in bug 1173689 didn't seem to be added as reftests.

heycam, this bug involves columns with writing-mode. Would you like to take a look at this bug?

(I feel this doesn't need to block enabling column-span on nightly, so I block it shipping column-span instead)

Flags: needinfo?(cam)

Thanks, I'll take a look at this one tomorrow!

Attached file test with column-width (obsolete) —

Here's a smaller test case with column-width and the columnar element having an orthogonal flow. I'm not sure why Chrome has the results that it has, but I'm just going to assume that its multicol support in the presence of orthogonal flows isn't right.

With the columns-span pref off, the columns fill up eagerly, so if the browser window is wide enough, there's a single column, and as you narrow the window, more columns appear. With the pref on, there's always only a single column.

First step is to work out what the correct behavior is...

Assignee: nobody → cam
Flags: needinfo?(cam)

Cameron, I'm re-evaluating which bugs worth blocking shipping column-span. I feel we should fix this. Are you still working on this? If not, I can take a look next week.

Flags: needinfo?(cam)

Perhaps it's worth seeing what effects the changes in bug 1095937 have here.

Per David's comment, let's unblock this bug from shipping column-span.

No longer blocks: ship-column-span

I'm going to punt this back to TY.

Assignee: cam → aethanyc
Flags: needinfo?(cam)

This testcase fixed the width property in .wrapper. (It was xwidth in comment 3's attachment.)

Attachment #9087596 - Attachment is obsolete: true

After implementing column-span, ColumnSetWrapperFrame and the inner
ColumnSetFrame have the same writing mode. In order to making
ColumnSetFrame's computed inline-size being unconstrained when the
multicol container is in orthogonal reflow, we need to test whether
ColumnSetWrapperFrame is in orthogonal reflow or not.

Attached file Testcase #2

Even with the attached patch, the layout is so deeply wrong so I'm not sure it makes much sense to land it without fixing the underlying issues more thoroughly (as dbaron hinted above).

Why are we stretching the column-set's block-size (width)? It seems to me we shouldn't. (Chrome has the correct block-size I think.)

Why is the column-set's inline-size (height) the size of just one column? Given that the available inline size is unconstrained, we should use the "fallback size" per which in this case is the ICB height. Then, per, the column-set should use its shrink-wrap size within that available space (I think), so in this case its inline-size should be 3 columns * 100px + 2 gaps * 2px = 304px (assuming the ICB height is larger than that).

BTW, is the min[max]-content inline size of a multi-column box defined anywhere?
I can't seem to find it in:

Hmm, nsColumnSetFrame::GetPrefISize uses 1 column unless it's specified, so I guess the shrink-wrap size in the above case really should be 100px since that's our max-content inline size. So that answers the 2nd question.

Chrome renders this test the same as Gecko, so I wonder how they get a different inline size in Testcase #2. I assume that's a just a bug in Chrome.

You need to log in before you can comment on or make changes to this bug.