column-fill: balance of a vertical block in orthogonal context incorrectly rendered
Reported by
goo...@gtalbot.org,
May 5 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Example URL: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/draft-column-fill-balance-orthog-block.xht Steps to reproduce the problem: Load self-explanatory reduced test http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/draft-column-fill-balance-orthog-block.xht What is the expected behavior? The word "TEXT" should remain unbroken Reference file: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/draft-column-fill-balance-orthog-block-ref.xht What went wrong? The word "TEXT" is broken in 2 Does it occur on multiple sites: No Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 60.0.3088.3 Channel: dev OS Version: Flash Version: irrelevant Notes ----- Colors (yellow, lime, blue) in the test are not part of the test: they only help visually figure out where the multi-column, the left column, the right column and the vertical block are. The line-height and setting of line-height are not part of the test. The 'font-family: Ahem' declaration block has been commented. With the Inspection developer tool, it can be conveniently enabled. Interestingly, when the multicolumn's height is set to a much smaller height (say, 49px), then "TEXT" is broken in 3 parts. Firefox 53 does not do that. The test is really about testing if the tested browser understand (and handles properly) the min-content inline size even if, even when its block's writing-mode is vertical. " balance Balance content equally between columns, if possible. " CSS Multi-column Layout Module 7.1 'column-fill' https://www.w3.org/TR/css3-multicol/#cf M. Stenshorne is the usual assignee regarding these matters. Suggested Component for this issue: Blink>Layout>MultiCol I expect to eventually submit this test to the CSS3 Multi-column Layout test suite.
,
May 12 2017
Able to reproduce the issue on Linux Ubuntu-14.04, Windows-7 and Mac-10.12.4 using chrome stable version 58.0.3029.110 and canary 60.0.3097.0 with the steps mentioned in comment#0.This is regression issue,broken in M50. Using the per-revision bisect providing the bisect results, Good build:50.0.2654.0 - (Revision:376054). Bad build: 50.0.2655.0 - (Revision:376333). CHANGE-LOG URL: https://chromium.googlesource.com/chromium/src/+log/d118af36c75a1be3073cb28ff28e9830716abf9d..a7b11018d068660d8a285d22dcd693eb064ef98e Unable to find the suspect from above CL,hence marking it as Untriaged. Could some one from dev team please help us in assigning this issue. Thanks..
,
May 12 2017
Suspect: https://chromium.googlesource.com/chromium/src/+/ef0bbaa58e53dc720970aec40a06f24ca66f7b0d
,
May 12 2017
Not necessarily a regression. This started to fail because we enabled support for unprefixed multicol properties back then. The test case relies on this (i.e. doesn't specify -webkit- prefixed properties).
,
Oct 20 2017
The assigned owner "mstensho@opera.com" is not able to receive e-mails, please re-triage. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 30 2017
,
Nov 7 2017
,
Feb 13 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ajha@chromium.org
, May 10 2017