1189131 - flex align-items center displaces text when writing-mode is vertical-rl

Status: RESOLVED DUPLICATE of bug 1267462

(Core :: Layout, defect)

Description

[rpatkar]

Attachment: verticalAlign.htm

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

See attached file for a simple repro. Removing the align-items: center tag causes the text to appear. Positioning is still incorrect for align-items values 'flex-end' and 'center'. Please open attached file in IE11 and Chrome to check expectation.

I am using FireFox version 39 where using about:config, I have enabled layout.css.vertical-text.enabled = true.


Actual results:

Text goes off box into ether.


Expected results:

Vertical text should have been placed at center of the box.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
20150729030208

(In reply to rpatkar from comment #0)
> I am using FireFox version 39 where using about:config, I have enabled
> layout.css.vertical-text.enabled = true.

In the future, please test experimental features in the latest Nightly in a brand new profile.
https://nightly.mozilla.org
https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce this in trunk.

Comment 3

[Thomas L Shinnick]

"writing-mode: vertical-rl" or 'vertical-lr' within flex item boxes causes wild offsetLeft values in FF.

I found this bug while researching prior to a new bug report I will submit.  After creating a 'pen' for this example, I checked for the same wild values I was seeing and indeed it is the text's DOM offsetLeft value that is being computed way far out in right field.  In that pen I surrounded the text with a span so that the offsetXxxxx values can be more easily displayed.  Please see
http://codepen.io/tshinnic/pen/BoGaov?editors=110

With this example I see the following offsetXxxxx values:

         Chrome 46         |          Edge             |        FireFox 42
                           |                           | 
  Top  Left  Height Width  |  Top  Left  Height Width  |  Top  Left  Height Width
   9    39     85     36   |   9    38     85     37   |   9  8947867  85     38

The wild value in my bug report (17895716) is almost exactly twice the value here.  I don't think it is a coincidence. (Maybe the one flex item here vs. two in my bug?)

Comment 4

[Thomas L Shinnick]

I submitted bug 1223180 "Flex + vertical writing-mode: flex items / text disappear" 
This and that both show offsetLeft wildly wrong, though using different approaches to flex.

Comment 5

[Jen Simmons [:jensimmons]]

Tagging to keep track of this bug.

Comment 6

[zak.knudsen]

Is there any update on this? Seems like it should be resolved after several years. I've created an updated codepen example as a fork of the example in a comment above. It uses the following CSS:

    .innerDiv {
      writing-mode: vertical-rl;

      display: flex;
    }

    .outerDiv {
      border:   1px solid black;
    }

Codepen: https://codepen.io/dotZak/pen/bLVyQV

Opening the above in Chrome 63.0, Safari 11.0.3, and Opera 49.0 identical, correct results.

offsetLeft =
Outer Div	8
Inner Div	9
Outer Div	9

Firefox 58

offsetLeft =
Outer Div	8
Inner Div	9
Outer Div	17895686

Putting `display: flex` on `#outerDiv` has the identical output in terms of calculation, e.g.:

    .innerDiv {
      writing-mode: vertical-rl;
    }

    .outerDiv {
      display: flex;

      border:   1px solid black;
    }

Comment 7

[Daniel Holbert [:dholbert]]

Yup, I'm working on this. I've got a patch-stack that I'll post over on bug 1267462 soon, and I confirmed that my current patches make us match your expectations on that CodePen  (8, 9, 9).

Comment 8

[zak.knudsen]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> Yup, I'm working on this. I've got a patch-stack that I'll post over on bug
> 1267462 soon, and I confirmed that my current patches make us match your
> expectations on that CodePen  (8, 9, 9).

Thanks, Daniel! Looking forward to having this fixed. Our agency is based in Hong Kong so a mix of English, traditional Chinese, and simplified Chinese is very normal for our work. `writing-mode` serves our uses very well; but this problem has been a pain for us when it comes to implementing layouts.

Greatly appreciate your efforts.

Comment 9

[Daniel Holbert [:dholbert]]

Sorry for the delays here. I've posted my patch stack over on bug 1267462 -- hopefully it'll be landing on Nightly 60 within a few days.

(In reply to Daniel Holbert [:dholbert] from comment #7)
> I confirmed that my current patches make us match your
> expectations on that CodePen  (8, 9, 9).

BTW - I confirmed that bug 1267462's patches make us match expectations (i.e. we match Chrome's rendering) on the original testcase here, too.  (attachment 8640830 [details])

Comment 10

[Daniel Holbert [:dholbert]]

I verified that latest Nightly shows the original testcase as having the text centered now.  And the codepen[1] from comment 6 looks good, too -- the elements don't get huge & overflow anymore, and we render the text at the left edge of the flex container now.

(One caveat, though -- contradicting myself from comment 7: On my machine, we now report the metrics as "8, 9, 11" vs. chrome's "8, 9, 9", which is slightly surprising. It looks like this isn't flexbox-specific -- I reduced a testcase and filed bug 1437218 on this.  I'm not sure how/why I observed different metrics in comment 7 -- it might've been a quirk of the intermediate patch that I had at that point, or a difference between platforms, or something else subtle.)

Anyway -- that subtle caveat aside, I think we can call this a duplicate of bug 1267462.

[1] https://codepen.io/dotZak/pen/bLVyQV