Open Bug 1464593 Opened 7 years ago Updated 3 years ago

Vertical writing mode applied on a child flex item causes wrong width when parent height is 100vh

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox60 --- wontfix
firefox61 --- fix-optional
firefox62 --- affected

People

(Reporter: martin.bohac, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-edge, testcase)

Attachments

(2 files)

firefox-layout-bug.png
26.46 KB, image/png
Details
Testcase from reporter.
436 bytes, text/html
Details
Attached image firefox-layout-bug.png —
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180516032328 Steps to reproduce: When troubleshooting a weird layout issue with overlapping items using vertical writing mode in flexbox, I discovered this bug. <!DOCTYPE html> <html> <head> <style> #parent{ display: flex; height:100vh; align-items: center; } #child{ display: flex; font-size:3rem; } #item1 { background-color: red; writing-mode: vertical-lr; } #item2 { background-color: lightblue; } </style> </head> <body> <div id="parent"> <div id="child"> <div id="item1">Item 1</div> <div id="item2">Item 2</div> </div> </div> </body> </html> Actual results: A parent flexbox with 100vh having a child flexbox which has an item with vertical writing-mode causes the child flexbox to have a wrong total width and limits width of other child flex items. This also causes a line break in item 2 for no reason. Strangely enough, this problem fixes itself temporarily when the browser window is resized. However on a subsequent page reload the problem re-appears. Expected results: Total width of the child flex box should be addition of widths of all flex items. Also no line break should appear in item 2. Tested in Chrome all ok, web inspector shows correct width and no line break in item 2. Screenshot attached.
Component: Untriaged → Layout
Product: Firefox → Core
Seems to be working as expected on Nightly.
I can reproduce the issue[1] on Win10 Nightly62.0a1 x64(20180528100448) [1] The text |Item 2| was line-breaked. It should not be line-breaked.
Status: UNCONFIRMED → NEW
status-firefox60: --- → wontfix
status-firefox61: --- → fix-optional
status-firefox62: --- → affected
status-firefox-esr52: --- → wontfix
status-firefox-esr60: --- → wontfix
Ever confirmed: true
Keywords: parity-chrome, parity-edge
Blocks: writing-mode
Oh, I see. Yeah, it's pretty weird that we're not even consistent when dynamically modifying the page. If I play with font-size, I get the expected results when going from 4rem -> 3rem for example, but not when I go 2rem -> 3rem.
I've also tried this just from curiosity in an older version of Firefox (57.0.1 on Linux) and found the behavior even worse. The width of "Item 1" proportionally grew with the width of the browser window :-O Which suggests there were some serious issues before with getting the correct width of vertical write mode objects. Could this be a regression? Or maybe the previous fixes didn't cater for flex box items?
> I've also tried this just from curiosity in an older version of Firefox > (57.0.1 on Linux) and found the behavior even worse. > The width of "Item 1" proportionally grew with the width of the browser > window I see and confirm this behavior with Firefox 52.8 ESR under Linux. - - - - - Martin, Can you explain what is the purpose or the meaning of having nested flexboxes (div#parent and div#child are flexboxes), like in your code/test? Because, as far as I can see, *_this is_* the triggering factor for the line break within "Item 2". - - - - - Here are 2 reduced tests (you need to download and install Ahem font which is downloadable from https://www.w3.org/Style/CSS/Test/Fonts/Ahem/ ) : http://www.gtalbot.org/BugzillaSection/Bug1464593-nested-flexbox-orthogonal-item-line-break-VRL-002.html http://www.gtalbot.org/BugzillaSection/Bug1464593-nested-flexbox-orthogonal-item-line-break-VLR-003.html Both tests cover both vertical writing-modes, do not resort to 'vh' unit and do not use 'align-items: center'. In both tests, you can see the line breaking occuring in <div id="itemEF">E F</div> by toggling/unchecking 'color: green' in developer inspection tool. I am using Firefox 62.0a1 buildID=20180604100129 under Linux Debian 9.4, 64bit. Firefox 62 fails those 2 tests. Chromium 66.0.3359.117 passes those 2 tests.
Keywords: testcase
Version: 60 Branch → Trunk
Alice0775 White, Please, can you report how Edge handles those 2 tests? And which version (16.16299 or 17.17134 ?) of Edge are you using? Thank you!
all green on Edge. Microsoft Edge 42.17134.1.0 Microsoft EdgeHTML 17.17134
Hi Gerard, I used nested flexboxes in the testcase because that's how I discovered it and also because the problem seemed to exist only in this scenario. You are right though about the 'align-items' property, which is irrelevant. However, the height of the parent does make a difference, as for any height values below 98vh the problem disappears!
Thank you Alice0775 White! :) - - - - - > However, the height of the parent does make a difference, as for any height > values below 98vh the problem disappears! Well, the height of the parent flexbox has no impact, no influence on the actual result (line breaking occuring in <div id="itemEF">E F</div>) in my 2 tests. The height of the parent flexbox in my 2 tests is 'auto'. The only triggering factors in my 2 tests are the nestedness of flexboxes and the orthogonal child.
I would guess that this is a case where we're incorrectly triggering a scenario where we *think* we don't need to reflow/remeasure a flex item (at the beginning vs. end of flex layout), because we think its size can't possibly have changed since the beginning of flex reflow, but it turns out it can.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: