In most cases, it's called with selection range which is collapsed in a text
node, but otherwise, the selection may be in an element which cannot have
text nodes. Therefore, before handling the insertion, it should look for
ancestor element which can have text nodes.
Note that this patch makes inserting text immediately before an inclusive
ancestor element whose parent can have a text node. However, both Blink and
WebKit ignores if there are invisible/empty inline nodes. So, even with
this patch, Gecko keeps failing in some tests of the WPT. It should be handled
in a follow up bug because doing it requires complicated code.
Differential Revision: https://phabricator.services.mozilla.com/D119065
I guess that this class is replaced with `AutoPlaceholderBatch`, and both of
them are followed by its instances. However, I don't want to change the
behavior in this bug. Therefore, this patch just moves it into `HTMLEditor`.
Depends on D119002
Differential Revision: https://phabricator.services.mozilla.com/D119003
Unfortunately, marking its constructor and destructor as `MOZ_CAN_RUN_SCRIPT`,
`Maybe<AutoSelectionRestorer>::reset()` and
`Maybe<AutoSelectionRestorer>::emplace()` cause bustage. Therefore, this patch
just mark them as `MOZ_CAN_RUN_SCRIPT_BOUNDARY`.
Note that `EditorBase::SavedSelectionRef()` cannot be moved to `HTMLEditor`
because `mEditActionData` is a private member of `EditorBase`.
Depends on D119001
Differential Revision: https://phabricator.services.mozilla.com/D119002
It should be treated as `uint32_t` since DOM API does so. However, there are
some exceptions:
* Result of `nsINode::ComputeIndexOf()`
* Result of `nsAString` methods
They return `-1` as not found, and anyway, they cannot treat large integer
than `INT32_MAX`. Therefore, this patch does not touch around them.
Differential Revision: https://phabricator.services.mozilla.com/D118933
`TextControlState` is alive during reframing, but `TextEditor` is not so.
Therefore, `TextControlState` should take the `PasswordMaskData` before
`TextEditor` is destroyed. And if `TextEditor` is recreated, and the value
hasn't been modified, unmasked range should be restored in the new editor.
Depends on D118757
Differential Revision: https://phabricator.services.mozilla.com/D118758
During a `TextControlState` alive, `PasswordMaskData` should be alive too.
Otherwise, we cannot keep unmasked range at reframing.
Depends on D118756
Differential Revision: https://phabricator.services.mozilla.com/D118757
The intermittent failure is caused by unexpected global reflow during the test.
If `<input type="password">` is reframed, `TextEditor` instance is recreated.
Then, the unmasked range of the editor stored by `TextEditor` is also lost.
Therefore, unmasked range is randomly lost by unexpected reflow.
If the global reflow is occurred by font list update etc which are not expected
by users, unmasked password field is unexpectedly masked. So, this is a real
bug of `TextEditor`.
So, unmasked range needs to be stored outside `TextEditor` for making its
lifetime longer than `TextEditor`. For doing it, first, `TextEditor` should
access password mask data via a pointer to a struct. Then, fortunately,
we need to allocate it only when the `TextEditor` is a password editor.
Depends on D118755
Differential Revision: https://phabricator.services.mozilla.com/D118756
In my understanding at fixing bug 1717156, `nsIEditor.eEditorMailMask` won't be
set to `TextEditor` instance. However for making consistent **spellchecker**
behavior on email composer, subject editor is also set this flag. So, we need
to drop the check in `SetFlags` and IsMailEditor.
Differential Revision: https://phabricator.services.mozilla.com/D118561
It's used only by password field, i.e., only by `TextEditor`, and used
temporarily. Additionally, there is some space in `TextEditor`. So, we
can get rid of it, and make `TextEditor` store it directly.
Note that this allows to skip expensive `nsIEditor::SetFlags()` calls by
`AutoRestoreEditorState`. This may improve setting `<input>.value` performance.
Differential Revision: https://phabricator.services.mozilla.com/D118266
Now, `nsIEditor::eEditorNoCSSMask` is used only in the editor internally.
And it's available and meaningful only with `HTMLEditor` instance. So,
we can get rid of it from `EditorBase`. Fortunately, `HTMLEditor` always
creates `CSSEditUtils` and it stores the raw value indicating whether the
editor manager enabled or disabled CSS. Therefore, we don't need new
member variable in `HTMLEditor` for storing the flag. And this allows us
to remove `nsIEditor::SetFlags()` override of `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D118265
Now, `EditorBase::IsTabable()` returns true only when it's an `HTMLEditor`
instance and `nsIEditor::eEditorAllowInteraction` is not set. Additionally,
nobody controls the flag of `TextEditor`. So, we can make the flag available
only with `HTMLEditor` instance, and `Tab` key handling in `EditorBase`
can be moved to `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D118264
Nobody (including comm-central and BlueGriffon) uses
`nsIEditor::eEditorFilterInputMask`. Therefore, we can get rid of this and its
accessor, `EditorBase::IsInputFiltered()`.
Differential Revision: https://phabricator.services.mozilla.com/D118263
With the previous patch, we know `nsIEditor::eEditorWidgetMask` always
matches with `EditorBase::IsTextEditor()`. And it's not referred from JS
(including comm-central and BlueGriffon). So, we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D118262
Some `nsIEditor::eEditor*Mask` flags are now only for `TextEditor` or
`HTMLEditor`. For making it clearer, add `MOZ_ASSERT` to the `SetFlags` and
each flag accessor.
Differential Revision: https://phabricator.services.mozilla.com/D118261
Developers may be confused at `IsTextEditor()` and `IsPlaintextEditor()`. When
the latter is `true`, the former is always `true`, but it may be `true` when the
editor is `HTMLEditor` too. So, it's a mode of `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D118246
`TextEditor` is now a final class, so, it should be marked as so. And this
patch modernize `virtual`, `override` and `final` keywords in them.
Differential Revision: https://phabricator.services.mozilla.com/D117998
When middle mouse paste is enabled and middle click occurs in an editable
content or it's in a document whose `designMode` is `on`, we shouldn't start
the autoscrolling because the click must be intended for pasting clipboard
content or primary selection to the position.
Differential Revision: https://phabricator.services.mozilla.com/D117987
`nsIDocumentEncoder.OutputRaw` was misspelled as `nsIDocumentEncoder.OutRaw`.
Then, I investigate the expected result more. Then, I see that when only this
flag is set, any markups should be ignored except `<br>`. Therefore, I modified
the 2 test results which check `<p>`, `<div>` and `<br>` elements.
Differential Revision: https://phabricator.services.mozilla.com/D117966
Masayuki Nakano
Kagami Sascha Rosylight
Ryan VanderMeulen
Andrew Halberstadt