Inline style should be preserved at deletion
Categories
(Core :: DOM: Editor, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox110 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
Details
Attachments
(3 files)
Currently, we don't preserve inline styles for next input at deletion. E.g., when abc<b>[def]</b>ghi, delete makes abc{}ghi, and insert "def" makes abcdef[]ghi. However, when abc<b>[def]</b>ghi, insert "def" makes abc<b>def</b>ghi, and also insert paragraph and insert "def" makes <div>abc</div><div><b>def</b>ghi</div>.
Additionally, we don't preserve inline style when abc{<b>def</b>}ghi, but Chrome does it. As far as I've tested, Chrome scans first visible text forwards from start boundary and preserve the style of it. We should follow it.
|
Assignee | |
Comment 1•1 year ago
|
||
This patch removes some traditional behavior check in the mochitest and
port it into expected results which match with the behavior of Chrome.
Almost all the new tests pass in Chrome, but some fails due to odd result in
Chrome. E.g., Chrome sometimes append style attribute with empty value.
Therefore, the expectations in this patch must be what Chrome developers
expected at implementing it.
Depends on D164004
|
|
Assignee | |
Comment 2•1 year ago
|
||
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
|
|
Assignee | |
Comment 3•1 year ago
|
||
Chrome preserves inline styles of first character in the deleting/replacing
if first visible thing is text. Safari preserves inline style of the first
content of the range (i.e., styles of <img> etc is also respected).
For now, due to the market share and Safari's behavior is not obviously better
than Chrome, let's try to emulate the Chrome's behavior. However, the rules are
complicated and probably depend on how it implements the deletion. Therefore,
this patch makes Gecko only scan following text node if selection range starts
from end of a text node.
Depends on D164520
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/ee463c9d27de part 0: Add WPT to check which inline style should be preserved r=m_kato https://hg.mozilla.org/integration/autoland/rev/2a9534dbca77 part 1: Make `HTMLEditor` preserve order of inline style elements too r=m_kato https://hg.mozilla.org/integration/autoland/rev/2097b869f8b0 part 2: Make `HTMLEditor` preserve style of following text if deleting/replacing range starts around inline element boundary r=m_kato
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/37522 for changes under testing/web-platform/tests
|
||
Comment 6•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ee463c9d27de
https://hg.mozilla.org/mozilla-central/rev/2a9534dbca77
https://hg.mozilla.org/mozilla-central/rev/2097b869f8b0
Upstream PR merged by moz-wptsync-bot
Description
•