Make `<br>` elemnet inserters of `HTMLEditor` aware of preformatted line break too
Categories
(Core :: DOM: Editor, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox135 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
Details
Attachments
(5 files)
In bug 1935065, HTMLEditor
will have LineBreakType
. Therefore, if we make the <br>
element inserters take a LineBreakType
parameter, we can make each caller consider the line break type with GetPreferrredLineBreakType
if and only if the caller may need to insert a preformatted linefeed.
Assignee | ||
Comment 1•2 months ago
|
||
For making most callers can insert either <br>
or a preformatted linefeed,
the inserter should handle both of them.
This patch makes PrepareToInsertLineBreak
which is renamed from
PrepareToInsertBRElement
to check whether the container can have the new
line break. Then, one test starts failing, but it's okay because it's a
test in <xmp>
which cannot have any elements, so, <xmp>
is super legacy
element and must not be used in these days especially in editable content.
Depends on D231655
Assignee | ||
Comment 2•2 months ago
|
||
Depends on D231656
Assignee | ||
Comment 3•2 months ago
|
||
Although this fixes a logical bug of the cases when aPointToInsert
is in an
inline element. I'm not sure how to reproduce the case because it's only caller
is the post processor, HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal
.
So, this bug could be reproducible only when the delete handler forgets to
clean up ancestor empty inline elements. So, I guess that this patch does
not change the behavior in the most cases.
Note that as I commented in bug 1936193, padding line break should always be
<br>
for avoiding them appear in .textContent
value. Therefore, this
method should not take LineBreakType
.
Depends on D231657
Assignee | ||
Comment 4•2 months ago
|
||
Its only caller is MaybeInsertPaddingBRElementForEmptyLastLineAtSelection
which just handles Selection
. Now, we have enough simpler utilities to
access Selection
. Therefore, we can get rid of the caller. Then, we can
reduce the number of selection update in
HTMLEditor::FormatBlockContainerAsSubAction
and AlignAsSubAction
.
Note that as I commented in bug 1936193, padding line break should always be
<br>
for avoiding them appear in .textContent
value. Therefore, this
method should not take LineBreakType
.
Depends on D231658
Assignee | ||
Comment 5•2 months ago
|
||
Depends on D231659
Backed out for causing build bustages @ EditorLineBreak.h
- Backout link
- Push with failures
- Failure Log
- Failure line:
/builds/worker/checkouts/gecko/editor/libeditor/EditorLineBreak.h:300:38: error: call to non-'constexpr' function 'nsIContent& mozilla::EditorLineBreakBase<CT>::ContentRef() const [with ContentType = nsCOMPtr<nsIContent>]'
Assignee | ||
Updated•2 months ago
|
Comment 9•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/24527c9e2d79
https://hg.mozilla.org/mozilla-central/rev/5ada411cd298
https://hg.mozilla.org/mozilla-central/rev/11fa2fe306cb
https://hg.mozilla.org/mozilla-central/rev/d9aca93f476b
https://hg.mozilla.org/mozilla-central/rev/5329436a678c
Description
•