963247 - contenteditable flex container (flexbox) has mispositioned cursor, for inserting text as a direct child of the flex container.

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P4)

Description

[hi]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

See example: http://jsfiddle.net/L789y/3/

Basically, 

1. create a contenteditable field. 
2. Apply `display: flex;` style to it. 
3. Click in field.



Actual results:

Cursor appears too low in field


Expected results:

Cursor should appear with proper bottom baseline offset (see non-flex styled contenteditable field in example fiddle).

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Confirmed. Here's the jsfiddle converted into an attached testcase (extended slightly to include a non-empty "display: flex" example).

Comment 2

[Daniel Holbert [:dholbert]]

(I can reproduce this in Nightly, 29.0a1 (2014-01-24), on Linux.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a trickier testcase, using "justify-content" and "align-items" to position the text-insertion point at the bottom-center, alongside an image. (And where the presence or absence of text makes a difference about where the image / text ends up, due to how "justify-content:space-around" behaves.)

Comment 4

[Daniel Holbert [:dholbert]]

This positioning issue boils down to this code, which is used for positioning the caret:
> 5887 nsFrame::GetPointFromOffset(int32_t inOffset, nsPoint* outPoint)
> 5888 {
[...]
> 5898       bool isRTL = (NS_GET_EMBEDDING_LEVEL(this) & 1) == 1;
> 5899       if ((!isRTL && inOffset > newOffset) ||
> 5900           (isRTL && inOffset <= newOffset)) {
> 5901         pt = contentRect.TopRight();

If the container is "display:block", isRTL is true there, and we use the top-right corner.  BUT, if it's "display:flex", then isRTL is false, and we skip that "pt" setting.

I don't know what NS_GET_EMBEDDING_LEVEL is about, but we're apparently not setting it correctly, on children of a flex container.

Comment 5

[Daniel Holbert [:dholbert]]

Sorry, comment 4 was intended for bug 1080832; posted it on the wrong contenteditable+flex bug.
 --> Tagging it (and this comment here) as obsolete, to avoid cluttering up this bug.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Seems to work fine now.