Bug 123204 – Combining vertical-rl writing mode, float: left and -webkit-text-combine: horizontal has unexpected result following r147588

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Layout and Rendering

[Antoine Quint]

Created attachment 214954 [details]
Test case

See the attached test case, which started rendering differently following http://trac.webkit.org/changeset/147588, a fix for https://bugs.webkit.org/show_bug.cgi?id=105692.

[Antoine Quint]

<rdar://problem/15297778>

[Glenn Adams]

This appears to be a case where, due to the transition to and from tatechuyoko (horizontal within vertical) mode, the line breaking context across the transition boundary should be cleared, i.e., you want to use:

m_renderTextInfo.m_lineBreakIterator.resetPriorContext();

at the the transition boundary.

[Koji Ishii]

(In reply to comment #2)
> This appears to be a case where, due to the transition to and from tatechuyoko (horizontal within vertical) mode, the line breaking context across the transition boundary should be cleared, i.e., you want to use:
> 
> m_renderTextInfo.m_lineBreakIterator.resetPriorContext();
> 
> at the the transition boundary.

The proposed fix here doesn't look correct; resetting line break context should not occur at inline element boundaries nor at before/after tatechuyoko. See:
# For line breaking before and after the composition,
# it is treated as a regular inline with its actual contents.
http://dev.w3.org/csswg/css-writing-modes/#text-combine-layout

I looked at the test case file, but from this bug description, the result and the expected is not clear to me.

[Koji Ishii]

oops, hit Enter too early; I mean, I wonder maybe this is by design. Antoine, can you clarify your expectations? I can then comment more properly.

[Antoine Quint]

Created attachment 215346 [details]
Expected rendering of test case

Attached a screenshot of my expectation, which matches what WebKit used to render up to r147588.

[Koji Ishii]

hm, the original looks more natural, but there should be a break opportunity before "1". I guess I need to look into more, but I suspect there has been a bug in box layout, and bug 105692 fix was right, but it brings hidden bug up.

I'll look further later.

[Koji Ishii]

I can't say exactly how and where, but my best guess is that intrinsic size calculation is incorrect when a vertical span contains a horizontal span, and Glenn's change made the bug clearer.

When tatechuyoko appears at the end of line, there should be break opportunities before and after. Exceptions are like when "!?" is in the tatechuyoko, because break before "!" is prohibited as per UAX#14.

I feel sorry that I guess this isn't really helpful advice...

[Koji Ishii]

Created attachment 215806 [details]
Test Case with longer text

[Koji Ishii]

See "Test Case with longer text"; this should not wrap, and is not related with bug 105692 (I suppose; I don't have older build.)

So a wild guess is that:
1. WebKit has a bug to calculate intrinsic size. A guess from the test case is that, it calculates character advances without writing-mode or tatechuyoko in mind. In the case of the attached test case, it might add *height* of "1", not *width*, and thus resulting box is smaller and lead to line break.
2. In the case of the attached test case, it does not break, there were no break opportunity.
3. With bug 105692 fixed, now the line has a break opportunity, and the original bug appear.

So, having a line break opportunity is correct, and we need to attack the original bug.

[Yuki Sekiguchi]

Created attachment 217381 [details]
Patch

[Koji Ishii]

The patch from Yuki looks quite good to me. Can we get someone to review?

[Brady Eidson]

Comment on attachment 217381 [details]
Patch

Assuming that patches for review since 2013 are stale, r-

[Ahmad Saleem]

This seems to be working fine in WebKit ToT (264533@main) and it is matching with Chrome Canary 115.

[Brent Fulgham]

Closing based on Ahmad's testing.