1951041 - Incompatible trailing white-space rendering when it's collapsible before a block boundary

Status: NEW

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

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Load the data URI in the URL field, and place caret at each line end.

Each line has a white-space which is collapsible with/without following <br>. On Chrome, users cannot put caret after the white-space, but on Firefox, users can put caret after the white-space.

This rendering result of Firefox was important for making the trailing white-space visible with a padding <br> especially for the editor module. However once we ship the new white-space normalizer of HTMLEditor which always use an NBSP for the trailing white-space which should be visible, this rendering difference becomes just a simple web-compat issue.

One of the implicit rule of HTMLEditor is, updating the DOM for users must expect. I mean, invisible white-spaces should be ignored and compute the editing result. E.g., if you type Backspace when <div>abc </div><div>[]def</div>, the result should be <div>abc def</div> if the trailing white-space is treated as visible, or should be <div>abcdef</div> if the trailing white-space is treated as invisible. So, keeping current rending keeps existing web-compat issue of the editor.

I think that at least, caret position should be changed not to put after the white-space.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Perhaps, we should just stop doing this?
https://searchfox.org/mozilla-central/rev/2f561d04a5344910a9b06410ebcef668f7e3508f/layout/generic/SelectionMovementUtils.cpp#521-527

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Looks like that .innerText spec believes that trailing white-spaces are invisible, see #4 of this.

4. If node is a Text node, then for each CSS text box produced by node, in content order, compute the text of the box after application of the CSS 'white-space' processing rules and 'text-transform' rules, set items to the list of the resulting strings, and return items. The CSS 'white-space' processing rules are slightly modified: collapsible spaces at the end of lines are always collapsed, but they are only removed if the line is the last line of the block, or it ends with a br element. Soft hyphens should be preserved.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, the trailing white-spaces are not painted as content of inline elements. So, it affects only the caret and selection painting. Additionally, according to the result on tryserver, we need to update PeekOffset methods too.