There are 3 bugs.
One is, `PendingStyles::TakeAllPreservedStyles` returns styles in reversed order
of setting styles, this unexpected order causes that `<font>` element is placed
innermost instead of outermost, thus, background color may be applied to shorter
area than text. Unfortunately, Chrome applies the style in fixed order, but
using same order as setting the styles is reasonable for us because we use
same code to apply multiple styles once.
Another is, `AutoInlineStyleSetter` extends the range to apply new style to
parents even if the given point is not in start or end of the first container.
Current code works fine if there is only one text node in an inline element,
but after un-setting a style, text nodes may be keep split. And also when we
apply new style, we create an empty text node for a placeholder of new text,
therefore, the range may be extended from the empty text node to before/after
its previous/next text node. Note that the latter case needs to work with
invisible things more, but this bug needs to be fixed ASAP due to the dead line,
and invisible things not so appear in inline elements. Therefore, it's okay
to leave it.
The other is, the delete handlers do not clear the cached styles (cached when
`HTMLEditor` starts handling it). If it's caused by a `Backspace` key press
in start of a block, `HTMLEditor` caches the style at caret (right paragraph),
then, collapse `Selection` to end of the ex-left block where may have different
style, then, when user types new text there, the cached style is applied into
to the new text **too**. Therefore, if `Selection` was collapsed and handling
a `Backspace` key press, the cached styles should be forgotten.
Depends on D168640
Differential Revision: https://phabricator.services.mozilla.com/D168865
The problem in Yahoo mail is, when you apply new font size to:
```
<div><font size="7">{}<br></font></div>
```
then, when you type text, you'll get:
```
<div><font size="7"><font size="4">abc<br></font></font></div>
```
because `HTMLEditor::CreateStyleForInsertText` does not check ancestors to
apply new style to empty text node which is created by the method for
placeholder. Of course, the other browsers update the existing
`<font size="7">` instead and we should follow it.
However, there are 3 problems:
1. Our editor may adjust insertion point to nearest editable text node if caret
in empty inline elements.
2. Our editor supports increase/decrease font size which have been removed from
`Document.execCommand`, but Thunderbird keeps using it, and that's implemented
with an independent method.
3. Our style editor code does not support applying style to collapsed selection.
Therefore, this patch does:
1. keep create empty text node to apply new style at specific point.
2. give up to use new path if there is preserved font size increment/decrement.
3. separate `HTMLEditor::SetInlinePropertiesAsSubAction` and add new path for
applying style to collapsed range.
Then, `HTMLEditor::CreateStyleForInsertText` can use
`HTMLEditor::SetInlinePropertiesAsSubAction` which supports handling new styles
with existing ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D166416
The problem in Yahoo mail is, when you apply new font size to:
```
<div><font size="7">{}<br></font></div>
```
then, when you type text, you'll get:
```
<div><font size="7"><font size="4">abc<br></font></font></div>
```
because `HTMLEditor::CreateStyleForInsertText` does not check ancestors to
apply new style to empty text node which is created by the method for
placeholder. Of course, the other browsers update the existing
`<font size="7">` instead and we should follow it.
However, there are 3 problems:
1. Our editor may adjust insertion point to nearest editable text node if caret
in empty inline elements.
2. Our editor supports increase/decrease font size which have been removed from
`Document.execCommand`, but Thunderbird keeps using it, and that's implemented
with an independent method.
3. Our style editor code does not support applying style to collapsed selection.
Therefore, this patch does:
1. keep create empty text node to apply new style at specific point.
2. give up to use new path if there is preserved font size increment/decrement.
3. separate `HTMLEditor::SetInlinePropertiesAsSubAction` and add new path for
applying style to collapsed range.
Then, `HTMLEditor::CreateStyleForInsertText` can use
`HTMLEditor::SetInlinePropertiesAsSubAction` which supports handling new styles
with existing ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D166416
Currently, `HTMLEditor` preserves styled elements with the reversed order in
the loop.
https://searchfox.org/mozilla-central/rev/d7d5c89ee7bc70dec0fd846689ca030f94931393/editor/libeditor/HTMLEditSubActionHandler.cpp#8638-8658
I.e., if `<b><i></i></b>` is restored in the HTML styling mode, it will be
restored as `<i><b>...</b></i>`. This blocks writing tests for bug 1789574.
Therefore, this should be fixed first.
(As I commented in the method, ideally we should store all inline elements and
restore all of them, but currently we don't need to do it. It requires redesign
of the style cache, but it seems that we don't know web apps which is broken by
current behavior. Therefore, I think that we should do it when we meet a
trouble with the behavior.)
Depends on D164519
Differential Revision: https://phabricator.services.mozilla.com/D164520
Additionally,
* `PropItem` -> `PendingStyle`
* `StyleCache` -> `PendingStyleCache`
* `AutoStyleCacheArray` -> `AutoPendingStyleCacheArray`
And finally, `PendingStyle` (formally `PropItem`) is changed to `class` and
its members are encapsuled.
Differential Revision: https://phabricator.services.mozilla.com/D155318
Masayuki Nakano
Cosmin Sabou