Bug 30208 – Possibly incorrect usage of line-break CSS property in editing tests

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Xan Lopez]

While trying to figure out why editing/selection/home-end.html was failing in the GTK+ port I checked the last part of the file, containing the problematic divs:

<div class="home-end-test" contenteditable style="line-break:before-white-space; width:100px">abcdefg abcdefg abcdefg a abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg </div>
<div class="home-end-test" contenteditable style="line-break:after-white-space; width:100px">abcdefg abcdefg abcdefg a abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg </div>

A few comments about this:

- According to the documentation available (http://developer.apple.com/mac/library/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/css/property/-webkit-line-break) line-break is useful to decide where to put line breaks in Chinese, Japanese or Korean test. This is pure Western text.

- 'before-white-space' does not even seem to exist, there's only 'after-white-space' or 'normal'.

- The line break does not happen at the same position that the test expects in my box (or the bots), since where 100px ends depends on font used, font sizes, etc...

So, what are those line-break rules supposed to achieve? Is there any way to get a cross-platform line break position so that we can share the expected results? What about 'before-white-space'?

I'll skip the test for now in GTK+ while we figure out a solution.

[Xan Lopez]

FWIW, the same thing happens in editing/selection/extended-selection.html, and also there's a reference in WebCore/editing/visible_units.cpp to 'before-white-space'.

[Martin Robinson]

This seems to be passing now. I'll unskip.