Follow-up to bbcc7547a3 which cleaned up browser/. This strips the
same modelines from the rest of the tree, excluding paths listed in
tools/rewriting/ThirdPartyPaths.txt.
Differential Revision: https://phabricator.services.mozilla.com/D295577
Although for making the further processing simpler and faster, we always
delete the following invisible things when modifying the preceding
content. However, `www.icloud.com/notes` users the invisible
preformatted linefeed as anchor for the post-processing of inserting
text. Therefore, this patch makes the inserting content handlers stop
deleting preformatted linefeed. However, for minimizing the risk, this
does not make them stop deleting unnecessary `<br>` elements.
Note that different from padding `<br>` element, the invisible
preformatted linefeed appears as a line break in the flattened text
content for IME. Therefore, preserving the linefeed makes IME not
receive unexpected deletion of a line break. It might be better for IME.
Interestingly, the other browsers delete padding linefeed if it's a
padding for current empty block. It seems that they do it before
inserting content. However, this patch does not do that. Perhaps, we
should write a method to prepare to insert content and share it wider
in a follow up bug (bug 2021218).
Differential Revision: https://phabricator.services.mozilla.com/D286202
This simplifies a lot position about inserting new padding line break
for the last empty line and each behavior is improved by the new API.
Differential Revision: https://phabricator.services.mozilla.com/D284965
Perhaps, we should stop using "visible" from the API names because
some API users use the methods while modifying the DOM. Therefore, the
new APIs explain the position of a line break or whether it's
significant or unnecessary from the layout point of view.
This patch adds API to check a line break position which may return
following/preceding block boundary's element and to scan following
block boundary with ignoring unnecessary line break which is done in
some places with calling
`WSRunScanner::ScanInclusiveNextVisibleNodeOrBlockBoundary()` twice.
Additionally, making the extant internal API mainly `HTMLEditUtils`
use the new API to do the correct handling.
Note that this makes `HTMLEditUtils::GetLeafNodeType` return `Ignore`
if the caller does not want invisible things and the node is in
`display:none` element. This change is required to keep passing some
tests whose editing host is `display:inline` and it's followed by
invisible text like `<script>`.
Differential Revision: https://phabricator.services.mozilla.com/D284962
Sylvestre Ledru