Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
The readonly flag of `HTMLEditor` can be set by chrome script or
`Document.execCommand("contentReadOnly")`. However, the XPCOM APIs should keep
working to update the editable content. E.g., if focused editor is a single
line text field, the app may want to change the value even if it's not editable
by the users.
Note that this patch does not fix all cases of all APIs because this is not
important for Firefox even though the status can be created by web apps (but
Firefox does not use XPCOM APIs basically, instead using XUL commands and it
should not work with readonly state since it may be kicked by user
interactions, e.g., executing a menu item or a shortcut key).
Therefore, it's enough to work it in current Thunderbird for now.
Differential Revision: https://phabricator.services.mozilla.com/D167353
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
It's always called with `DeleteSelectedContent::Yes`. Therefore, the argument
is not required. Then, its name can be `InsertFromTransferableAtSelection`.
Differential Revision: https://phabricator.services.mozilla.com/D158483
It just creates `HTMLWithContextInserter` and calls its `Run()`. Then, `Run()`
works as a sub action handler. Therefore, we can make `DoInsertHTMLWithContext`
(which sounds like a helper class of a handler method) a sub action handler.
Then, it can handle the optional insertion point in it and
`HTMLWithContextInserter::Run` does not need to handle it.
Differential Revision: https://phabricator.services.mozilla.com/D158482
They use `bool` arguments a lot. Therefore, some call-sites are hard to read.
They should be replaced with `enum class`es. Note that this patch does not
make the raw value of new `enum class`es to `bool` unless they are used in the
heap.
Differential Revision: https://phabricator.services.mozilla.com/D158481
Any callers do not refer "ignored", "handled" and "cancel" state without
checking whether the method returns error or not. Therefore, error state
can be (and should be) managed by `mozilla::Result`'s error state.
Perhaps, it should store a caret position later because deletion handlers
of `HTMLEditor` use it, but update `Selection` immediately.
Differential Revision: https://phabricator.services.mozilla.com/D158080
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
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
I've already made a caller of `HTMLEditor::ClearStyleAt`,
`HTMLEditor::CreateStyleForInsertText`, in bug 1770877, so this fixes a bug of
the patch.
`HTMLEditor::ClearStyleAt` is still updates `Selection` only in some cases.
And one of the caller has not handle the `Selection` update. Therefore, once
it completely stop touching `Selection`, `ComputeEditingHost` will fail and
the other paths update `Selection`, so it should do it too. (Without the
change, `test_dragdrop.html` fails.)
Finally, we don't need `EditResult` anymore because we have
`Result<EditorDOMPoint, nsresult>`.
Differential Revision: https://phabricator.services.mozilla.com/D154343
Similar to the previous patch, and for consistency between editor helper
classes, we should make result of getter methods of `EditorDOMPointBase` too.
Differential Revision: https://phabricator.services.mozilla.com/D153841
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Its callers check `EditorBase::Destroyed()` with at least adding 4 lines, and
some callers do not check this important state. So, we should make it check
`Destroyed()` at last and omit the additional error check in the caller sites.
Note that it's a virtual method, but `HTMLEditor` checks whether it's a
removable node or not. So, we should can merge it into `EditorBase`. This
patch does it too.
Differential Revision: https://phabricator.services.mozilla.com/D148084
It's currently computes the corresponding editing host from the focus node of
`Selection` with climbing up the DOM tree. So, it does not just return a stored
element. Therefore, some callers use it multiple times. For avoiding it, we
should rename it to explain that it computes the editing host.
Note that I think that we should make it takes a node to compute editing host
without `Selection` for solving the case of no selection ranges. Therefore,
I don't like to include more information into the name.
Differential Revision: https://phabricator.services.mozilla.com/D147504
This patch also makes that `HTMLWithContextInserter::InsertContents`
collect moving children first. Then, move each one with a transaction.
This is standard manner in these days to avoid infinite loop caused by
moving the removed child back by a mutation event listener.
Differential Revision: https://phabricator.services.mozilla.com/D144658
Now, it does not require to update selection, and its result may have a point
to put caret it is used to doing. This patch makes it stop collapsing selection
after each split, and instead, makes all callers of it collapse selection if
it's (probably) necessary.
Note that the method may not split any nodes but return it as "handled".
Therefore, the callers do not check whether a splitting node occurred **but**
suggesting point to put caret is invalid or the other cases. Therefore, in
strictly speaking, this patch changes the existing behavior, but it should not
affects web apps in the wild because of the low usage of the legacy mutation
event listeners.
Differential Revision: https://phabricator.services.mozilla.com/D144650
This patch allows methods which split some nodes to return new candidate
caret position and makes callers of them consider whether applying it to
the selection immediately or not.
Differential Revision: https://phabricator.services.mozilla.com/D144648
Some of them were `HTMLEditor` so that we need to fix it to `EditorBase`, and
also this patch fixes `NS_ERROR_EDITOR_DESTROYED` handling around them.
Differential Revision: https://phabricator.services.mozilla.com/D143815
Capturing everything causes increasing the binary size especially of debug
build so that we should add more arguments to the callback and make some
lambda methods capture individual variables when they are necessary.
Note that nobody uses the 3rd argument, `aPointToInsert`, it'll be used to
fix bug 1759370 and makes the change smaller.
This decreases the size of xul.dll of debug build on Windows 123MB from 323MB.
I tried to delete all captures from the lambdas, but it does not affect to the
binary size and it makes the code harder to read, killing static analysis.
Therefore, we should not do it.
Depends on D141196
Differential Revision: https://phabricator.services.mozilla.com/D141447
For avoiding simple back-out of the patches when we get serious regression
reports, we should have a pref to disable the new pref.
Differential Revision: https://phabricator.services.mozilla.com/D140475
With the change of the previous patch, `HTMLEditor` won't delete empty elements
in the inserted HTML content. However, at bug 1123505, it intentionally tried
to delete empty list elements which have no list item elements since such
list elements won't be editable. Therefore, the following patch makes some
tests in `test_copypaste.html` fail.
https://searchfox.org/mozilla-central/rev/3de56eb5f266f523340e739ae1b53258e0a95dfe/dom/base/test/copypaste.js#343,360
Unfortunately, the broken behavior is compatible with Chrome (Chrome accept
list elements which have no list item elements), but it does not make sense for
Gecko's builtin editor. Therefore, I think that we should keep our traditional
behavior with deny-list.
This patch makes `FragmentFromPasteCreator` delete list elements which have no
list item elements and are empty from the inserting document fragment.
Differential Revision: https://phabricator.services.mozilla.com/D136211
This is same issue as bug 1747008, but the remover is different method, that is
`HTMLEditor::RemoveEmptyNodesIn` called by
`HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal`. It should be called
only when the flag which was added by bug 1747008 is **not** set to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D136210
Starting from bug 1730429, we strip empty inline elements at caret for
compatibility with Blink/WebKit. However, we should not do it for the elements
which are intentionally inserted (from `inserthtml` command, paste and DnD).
All the cases are handled by `HTMLEditor::HTMLWithContextInserter` so that
it should prevent the new clean up with `TopLevelEditSubActionData`.
Note that `inserthtml` command handling of Blink is really odd. It inserts
the empty inline elements of the adding testcases into different place so that
Chrome does not pass the new tests. However, it does not make sense and I
believe that it's out of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D135195
First, left/right node accessors are not used so that we can get rid of them.
However, we should have similar methods which can retrieve original node and
new node. Therefore, this adds `GetNewContent()` and `GetOriginalContent()`.
Next, `SplitPoint()` should return both `EditorDOMPoint` and `EditorRawDOMPoint`
for avoiding unnecessary conversion from `EditorRawDOMPoint` to
`EditorDOMPoint`. Therefore, this patch makes it a template method too.
Finally, this patch adds helper methods to get point of each related content.
E.g., `AtNewContent()` corresponding to `GetNewContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D131748
It touches the DOM tree only with `SplitNodeTransaction()` and it now returns
`NS_ERROR_EDITOR_DESTROYED` so that the callers don't need to check whether
the editor is destroyed or alive by themselves.
Depends on D131043
Differential Revision: https://phabricator.services.mozilla.com/D131044
