Applying CSS "writing-mode: vertical-rl;" to text inside one flex item, while also having a second flex item with plain text, causes the second flex text to disappear. What happens: The second flex item is not displayed in FireFox. What should happen: The second flex item and its text should be displayed, as it is in the Chrome, IE 11, and Edge browsers. I've created a 'pen' to more easily view the problem, at http://codepen.io/tshinnic/pen/YyRKEZ After looking into this I discovered that, uniquely, FireFox was computing a *wild* value for offsetLeft for the second flex item. It was set to 17895716, which is about 3 miles to the right of the screen. Disabling the "writing-mode: vertical-rl;" now displayed the missing text in the same manner as the other browsers. The text also disappeared with 'vertical-lr' but any other 'writing-mode' valid or invalid value would display the text. Here are some example 'offsetXxxxx' values from this pen's flex items: Chrome 46 | Edge | FireFox 42 | | .section-header | | Top Left Height Width | Top Left Height Width | Top Left Height Width 81 9 167 37 | 81 9 119 65 | 82 9 167 38 | | .section-content | | Top Left Height Width | Top Left Height Width | Top Left Height Width 81 46 167 162 | 81 74 119 162 | 82 17895716 167 161 where .section-header is the first leftmost flex item, and .section-content is the second disappearing flex item. Note that while I keep saying "the text disappeared", adding a 'background-color' demonstrates that it is the whole flex item <div> that is disappearing (translated off the map). This problem is obviously 'related' to bug 1189131 "flex align-items center displaces text when writing-mode is vertical-rl" although that bug report ascribes the difficulty mistakenly. I've created a 'pen' for that also at http://codepen.io/tshinnic/pen/BoGaov Interestingly, the wild value here, 17895716, is almost exactly twice the wild value seen for bug 1189131, which was 8947867. There are two flex items here and only one at the other bug. Coincidence? This problem was initially reported at https://github.com/philipwalton/flexbugs/issues/98 by https://github.com/MichaPau
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
Version: 42 Branch → Trunk
We render this testcase differently from Chrome and I suspect their layout is the correct one. Is this the same issue as this bug?
Likely yes. (Also, this is probably a variant of bug 1267462 (which is some not-quite-finished business with flexbox + logical coordinates, which manifests as bugs with vertical writing modes + flexbox).)
Depends on: 1267462
I have exactly the same issue. Here is another, perhaps simpler, test case: http://jsbin.com/qomemuj/1/edit?html,css,output
It's a PitA that Firefox blows up over the combination of vertical writing mode and flexible box layout. Vertical writing mode and the fact that it flips the behavior of percentage-based paddings is the only solid way to generate content that is set to a fixed aspect ratio where the *width* follows from the *height*. E.g. http://jsbin.com/wiwotagefi/1/embed?html,output Try opening that example in a browser which implements this without problem, like Chrome, and use the resize grip on the textarea to resize the 'content' presented next to the image. There's basically no way to get that effect in Firefox.
I've got patches up on bug 1267462, and I've verified that they make Firefox change to produce the correct rendering on the testcases from comment 0, comment 1, and comment 3. It does not help with Comment 4's testcase, but I'll investigate and figure out what's going on there.
Flags: needinfo?(jfkthame) → needinfo?(dholbert)
I filed bug 1436896 for the testcase in comment 4. It's got some subtler pieces than the rest of the testcases here (in particular: percent horizontal padding in a vertical-WM flex item, which resolves against the flex item's height, which is initially indefinite but later becomes definite). See that bug page for more details.
I verified that this bug's initial testcases (comment 0, comment 1, and comment 3) are fixed in latest nightly, by bug 1267462. --> resolving as duplicate of that bug.
Status: NEW → RESOLVED
Last Resolved: a year ago
No longer depends on: 1267462
Resolution: --- → DUPLICATE
Duplicate of bug: 1267462
You need to log in before you can comment on or make changes to this bug.