In the historical reason, some of them still take `nsINode*`. In these
days, converting from `nsINode` to `nsIContent` or `Element` is faster
than before and most callers already use `nsIContent`. Therefore, we
should make them take `const nsIContent&`.
Only some methods, allowing callers use pointer makes them simpler.
Therefore, only some methods have overloads which take
`const nsIContent*` instead.
Differential Revision: https://phabricator.services.mozilla.com/D265525
In the historical reason, some of them still take `nsINode*`. In these
days, converting from `nsINode` to `nsIContent` or `Element` is faster
than before and most callers already use `nsIContent`. Therefore, we
should make them take `const nsIContent&`.
Only some methods, allowing callers use pointer makes them simpler.
Therefore, only some methods have overloads which take
`const nsIContent*` instead.
Differential Revision: https://phabricator.services.mozilla.com/D265525
To distinguish whether a DOM modification is expected one or not, we
need to know what the editor is doing and what is expected result by
the mutation.
This patch adds some wrapper classes of DOM API calls and make all
callers of them except the target is very new node which has not been
connected to any DOM.
Differential Revision: https://phabricator.services.mozilla.com/D260587
This reverts commit 73d1ab198c.
Revert "Bug 1973655 - part 2: Make `HTMLEditorMutationObserver.cpp` r=m_kato"
This reverts commit 8603a23c33.
Revert "Bug 1973655 - part 1: Make the editor module not call DOM API to modify the DOM directly r=m_kato"
This reverts commit a8abe8d84c.
To distinguish whether a DOM modification is expected one or not, we
need to know what the editor is doing and what is expected result by
the mutation.
This patch adds some wrapper classes of DOM API calls and make all
callers of them except the target is very new node which has not been
connected to any DOM.
Differential Revision: https://phabricator.services.mozilla.com/D260587
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.
Differential Revision: https://phabricator.services.mozilla.com/D231656
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.
Differential Revision: https://phabricator.services.mozilla.com/D231656
Computed color values will not be in the correct format, closer to the
one specified by the author. This also means that colors accross the
code are stored now as AbsoluteColor or StyleAbsoluteColor. This allows
color space/gamut information to be available for use.
Some animation related test failures had to be changed, because colors
now has greater precision. Animated a color now causes a lot more
animation updates, which was not initially expected. See the bug for
discussion.
Differential Revision: https://phabricator.services.mozilla.com/D171021
This patch creates a base class of `EditorInlineStyle`, the name is
`EditorElementStyle`. It requires only attribute of HTML. However, it's
obviously different from `EditorInlineStyle`'s rule which is `mHTMLProperty`
cannot be `nullptr`. Therefore, the methods which can treat only
`EditorInlineStyle` do not want the data only whose attribute is not `nullptr`.
For solving this issue at build time, this approach is better than renaming
`EditorInlineStyle` and make it have the new mode.
Depends on D162513
Differential Revision: https://phabricator.services.mozilla.com/D162514
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
The following patches touch the logic to restore selection after handling
commands. However, it seems that they are not tested because I found some
regressions by manual testing, but didn't cause orange on tryserver.
`outdent-preserving-selection.tentative.html` causes a crash due to the
`MOZ_ASSERTION` in `HTMLEditor::HandleOutdentAtSelectionInternal`. It means
that I misunderstand the logic and had put the assertion. I should fix it
later with reading the complicated code again. For now, I just change it
to `NS_WARNING_ASSERTION` instead.
And also `test_cmd_absPos.html` is the first test to check toggling `position`
between `static` and `absolute`. Therefore, it detects wrong `MOZ_ASSERT`s
which test whether `EditActionData` or `TopLevelEditSubActionData` is created
or not **before** they create them by themselves. So, this patch removes the
wrong assertions.
Differential Revision: https://phabricator.services.mozilla.com/D152962
It's always work with `Selection` ranges. Then, it should be treated within
`AutoRangeArray` which can be initialized with `Selection` ranges automatically.
Then, we can making `HTMLEditor` simpler.
Note tha this tries to make it get editing host when the corresponding
public method is called (after dispatched `beforeinput` event if handling a
users' operation). However, as commented in
`HTMLEditor::SetParagraphFormatAsAction`, it breaks a tricky crash test.
Therefore, only the format block path computes it after the preparation.
Differential Revision: https://phabricator.services.mozilla.com/D149079
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
It returns the anonymous `<div>` element if the instance is a `TextEditor`, and
compute editing host otherwise. So it's unclear what it returns. Additionally,
all users except `EditorBase::CreateTransactionForCollapsedRange` are the
methods of `HTMLEditor`. Therefore, we should remove it and unwrap the code
which it's done.
Differential Revision: https://phabricator.services.mozilla.com/D147503
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
At initializing new element which has not been connected, undo transactions
are not necessary because just removing the new element gets same result for
users. Therefore, they should be able to work without transactions.
Differential Revision: https://phabricator.services.mozilla.com/D140468
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
The testcase hits the assertion because `CreateNodeTransaction::DoTransaction()`
returns error, but it's not handled by `HandledInsertParagraphInParagraph()`
so that we should make `InsertBRElementWithTransaction()` and its callees
should return error if they meet unexpected cases.
Depends on D113471
Differential Revision: https://phabricator.services.mozilla.com/D113472
When the grabber to move absolutely positioned element is disabled,
`HTMLEditor::HideGrabberInternal()` is called to delete it. However,
it does not reset dragging state. Therefore, `mousemove` event listener
will try to handle drag even after the grabber is removed.
This patch makes `HideGrabberInternal()` reset the dragging state to
make the event listener stop handling the drag action.
However, I hit a buggy assertion in `EventStateManager`. It tries to
set active state to parent of the grabber (in this case, absolutely positioned
element). However, editable element in `contenteditable` cannot have
active state. Therefore, `leaf` becomes `nullptr`, but `newleaf` is the
absolutely positioned element. Therefore, this patch adds this condition
into the `MOZ_ASSERT`.
Differential Revision: https://phabricator.services.mozilla.com/D93632
Although we use CSS property for Inline table editing UI, we use edit
transaction for it unfortunately. When hiding this UI, since removing
element doesn't use edit transaction, transaction will be canceled before
showing this UI.
It is unnecessary to use edit transaction for UI, so we shouldn't use it.
Differential Revision: https://phabricator.services.mozilla.com/D90056
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
The root cause of this bug is a bug of async `ScrollSelectionIntoView` that
is what it won't be canceled even if web app changes scroll position with
any API. Fixing it is really risky and this bug affects an existing website.
Therefore, this patch makes the constructors of `AutoPlaceholderBatch` take
whether do or do not `ScrollSelectionIntoView` when it's destructed. And
makes `HTMLEditor::SetInlinePropertyAsAction()` not request
`ScrollSelectionIntoView` for taking back the traditional behavior.
Note that this patch does not make it an optional argument because it's hard to
guess that it'll run `ScrollSelectionIntoView` automatically.
Differential Revision: https://phabricator.services.mozilla.com/D87819
Masayuki Nakano