1230455 - spaces at the ends of lines in a <span style="unicode-bidi:isolate"> inside a <pre> are displayed at the wrong end of the line

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Aharon (Vladimir) Lanin]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

Go to:

data:text/html,<pre><span style="unicode-bidi:-moz-isolate; direction:rtl">x.   %0Dy.  %0Dz. </span></pre>


Actual results:

The spaces are displayed at the left end of each line.

Please note that this is not the case when the unicode-bidi:-moz-isolate is replaced with unicode-bidi:embed. The latter displays correctly.


Expected results:

The periods in each line should be displayed flush with the left margin, i.e. to the left of the letter, but the spaces should be displayed on the right end of each line.

I believe that this is the correct behavior based on the the Unicode and CSS specs. My reasoning:

- A newline inside a <pre> constitutes a bidi paragraph break.

- Thus, each of the lines in the test case is a separate bidi paragraph

- CSS writing modes level 3 says: "the paragraph embedding level must be set [...] according to the direction property of the paragraph’s containing block"

- Thus, each line's paragraph embedding level is 0 (i.e. LTR), even though it is inside the direction:rtl span, because its containing block is the <pre>, which has the default direction:ltr, and thus embedding level 0.

- CSS writing modes level 3 says: "[unicode-bidi:isolate] corresponds to inserting an LRI (U+2066), for direction: ltr, or RLI (U+2067), for direction: rtl, at the start of the inline box, and a PDI (U+2069) at the end of the box."

- It also says: "If an inline box is broken around a bidi paragraph boundary (e.g. if split by a block or forced paragraph break), then the HL3 bidi control codes assigned to the end of the box are also added before the interruption and the codes assigned to the start of the box are also added after it. (In other words, any embedding levels, isolates, or overrides started by the box are closed at the paragraph break and reopened on the other side of it.)"

- Thus, each line should be treated as starting with an RLI and having a PDI after the spaces.

- UBA's L1 says: "On each line, reset the embedding level of the following characters to the paragraph embedding level: [...] Any sequence of whitespace characters and/or isolate formatting characters (FSI, LRI, RLI, and PDI) preceding a segment separator or paragraph separator".

- Thus, on each line, the embedding level of the trailing spaces and the PDI should be reset to the paragraph embedding level, which we determined above as 0. This should put both the spaces and the PDI at the right end of the line.

Comment 1

[Simon Montagu :smontagu]

(In reply to Aharon (Vladimir) Lanin from comment #0)

Thank you very much for the detailed analysis, Aharon!

> - It also says: "If an inline box is broken around a bidi paragraph boundary
> (e.g. if split by a block or forced paragraph break), then the HL3 bidi
> control codes assigned to the end of the box are also added before the
> interruption and the codes assigned to the start of the box are also added
> after it. (In other words, any embedding levels, isolates, or overrides
> started by the box are closed at the paragraph break and reopened on the
> other side of it.)"
> 
> - Thus, each line should be treated as starting with an RLI and having a PDI
> after the spaces.

There is code in nsBidiPresUtils.cpp to do this closing and reopening for embedding levels and overrides, but it doesn't yet handle isolates. (Called from nsBidiPresUtils::ResolveParagraphWithinBlock, aBpd->ClearBidiControls adds the control codes at the end of the paragraph and the loop at the end of aBpd->ResetData adds them back to the beginning of the next one)

(FWIW, the patch in bug 1160847 would fix this)

Comment 2

[Simon Montagu :smontagu]

That said, I'm not sure that this bug is really a bug, or rather I suspect that it may be pointing to a bug in the UBA: doesn't giving trailing spaces in a bidi-isolated element the paragraph direction instead of the element direction contradict the concept of bidi isolation?

Comment 3

[Simon Montagu :smontagu]

Attachment: Testcase

This illustrates what I meant in the last comment with a relatively realistic example: I think it's a reasonable expectation that with bidi isolation the trailing spaces will line up on the left.

Does this make sense? If so I'll bring it up on the Unicode list, and formally propose a change if the idea doesn't get shot down.

Comment 4

[Aharon (Vladimir) Lanin]

I think that the UBA is correct as is; this treatments of isolates by L1 is an intentional feature, even though it intentionally takes away a bit from the isolates' isolation. Isolates are meant to be what embeddings would have been if someone had thought of it 15 years ago. Just as having trailing spaces wind up at the start of the line (from the paragraph's point of view) sucks when resulting from embeddings, so it sucks when it results from isolates.

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

It seems the patch in bug 1160847 could fix this.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

Fixed by bug 1160847.