A `focus` event listener may change focus from the `focus` event target
and it's not good thing to run content script before dispatching
`eFocus` event via `OnFocus` of the editor classes. Therefore, let's
make `EditorEventListener` restart listening to `eFocus` event and
handle the things which are not referred by web content script after
the `focus` event propagation in the web content.
Unfortunately, this cannot drop `MOZ_CAN_RUN_SCRIPT` from
`TextEditor::OnFocus` nor `HTMLEditor::OnFocus` because selection
listeners may run. However, they should not run web content script.
So, the preprocessing of `eFocus` or `eBlur` event becomes much safer
by this change.
Differential Revision: https://phabricator.services.mozilla.com/D294361
`TextEditor::OnFocus()` is called when
`HTMLInputElement::PreHandleEvent()` or
`HTMLTextAreaElement::PreHandleEvent()` is called, that means that when
it's called, the `eFocus` event has not been dispatched yet.
On the other hand, flushing the layout in `TextEditor::OnFocus()` was
added in bug 1755104 for making `TextEditor` stop handling `eFocus`
event if the focus is redirected by a preceding `focus` event listener.
However, now, there is no preceding `focus` event listener of
`TextEditor::OnFocus()`. Therefore, we don't need to do that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D294360
This adds some options which ignore some types of inline elements.
For example, `IgnoreAnyEmptyInlineContainers` is useful to scan previous
or next editable point because Chrome ignores empty inline elements when
deleting from next to an inline element.
`IgnoreInvisibleInlineVoidElements` is useful to scan invisible line
break from end of a block or checking a line break is invisible because
visible inline element makes a line after the last line break. E.g.,
```html
<div>ABC<br><span></span></div>
```
This shows only one line. However,
```html
<div>ABC<br><span style="border:1px solid"></span></div>
```
This shows 2 lines in the `<div>`.
Additionally, renaming the existing `LeafNodeType` values for making
them easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D277520
This reverts commit 5ccf392dce.
Revert "Bug 1998077 - part 6: Reimplement `HTMLEditUtils::Get(First|Last)Child()` and `HTMLEditUtils::Get(Next|Previous)Sibling()` with `LeafNodeOptions` r=m_kato"
This reverts commit 12eb928cb5.
Revert "Bug 1998077 - part 5: Replace the remaining `HTMLEditUtils::Get(Next|Previous)Content()` with new ones based on `Get(Next|Previous)LeafNodeOr(Next|Previous)BlockElement()` r=m_kato"
This reverts commit 58b4243d10.
Revert "Bug 1998077 - part 4: Replace some callers of `HTMLEditUtils::Get(Next|Previous)Content()` with `HTMLEditUtils::Get(Next|Previous)LeafContentOr(Next|Previous)BlockElement()` r=m_kato"
This reverts commit dd46967eb4.
Revert "Bug 1998077 - part 3: Add new options to ignore empty/invisible leaf nodes r=m_kato"
This reverts commit ca50a4a628.
Revert "Bug 1998077 - part 2: Add `WSType::EmptyInlineContainerElement` r=m_kato"
This reverts commit 4a5d93d631.
Revert "Bug 1998077 - part 1: Make `HTMLEditUtils::IsVisibleElementEvenIfLeafNode` work better if primary frame is available r=m_kato"
This reverts commit b42dc9d35f.
This adds some options which ignore some types of inline elements.
For example, `IgnoreAnyEmptyInlineContainers` is useful to scan previous
or next editable point because Chrome ignores empty inline elements when
deleting from next to an inline element.
`IgnoreInvisibleInlineVoidElements` is useful to scan invisible line
break from end of a block or checking a line break is invisible because
visible inline element makes a line after the last line break. E.g.,
```html
<div>ABC<br><span></span></div>
```
This shows only one line. However,
```html
<div>ABC<br><span style="border:1px solid"></span></div>
```
This shows 2 lines in the `<div>`.
Additionally, renaming the existing `LeafNodeType` values for making
them easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D277520
It's called by `TextEditor` after (maybe) modifying the value before
dispatching `input` event.
First, it updates the enabled state of the undo/redo commands. However,
it's managed by the window. Therefore, it does not make sense to depend
on the frame.
Then, it updates the various state of the related objects. For making
them work with destroyed `TextEditor`, this patch makes `TextEditor`
keep storing the latest value with caching the `Text` while it's
handling something.
Differential Revision: https://phabricator.services.mozilla.com/D276790
For making the implementation is for which editor, the method should be
a pure virtual function and `TextEditor` and `HTMLEditor` implement it
as they needed.
Additionally, it should return `Result` to avoid the caller to use
fallback IME state even temporarily.
Differential Revision: https://phabricator.services.mozilla.com/D274386
Once the editor is destroyed while dispatching `beforeinput` event,
e.g., by a reframe of the text control frame, `AutoEditActionDataSetter`
marks "the editor has destroyed during my lifetime". Then, nested
`EditAction`s always fail because the parent `AutoEditActionDataSetter`
thinks the editor is not available.
However, the editor can be reinitialized immediately. Then, the nested
`EditAction`s should work (note that it does not mean that another user
input is handled, `AutoEditActionDataSetter` is used by some query
methods too). Therefore, this patch adds a new `bool` member to store
whether the editor is initialized again.
I think we could reset `mEditorWasDestroyedDuringHandlingEditAction`,
but I'm afraid to do that because it forgets the destroyed thing
completely and some features may need to abort handling something even
if the editor is restored since the editable nodes are recreated.
Therefore, this patch adds a new `bool` member for making this change
safer and anybody can access the details of the state.
Differential Revision: https://phabricator.services.mozilla.com/D271559
It's important to verify that when `TextEditor` is destroyed temporarily
if the text control frame is reframed by the web app during text input.
Therefore, this patch adds the logger for the timings of `TextEditor`
creation, destruction, focus and blur **and** the common `InputEvent`
dispatcher.
Differential Revision: https://phabricator.services.mozilla.com/D271558
Textarea no longer creates newlines in the middle (it only has a
trailing newline for caret positioning purposes), so this is equivalent
but avoids going through nsDocumentEncoder, nsPlainTextSerializer and so
on...
Differential Revision: https://phabricator.services.mozilla.com/D267509
This patch updates all occurrences of the type `nsTextFragment` into its new name, `mozilla::dom::CharacterDataBuffer`.
It also updates the includes, including sorting.
Differential Revision: https://phabricator.services.mozilla.com/D259867
`GetTextNode()` requires that the instance has already been initialized since
it requires the native anonymous `<div>`. And `IsEmpty()` is a public method.
Therefore, it should return `true` if there is no editor root, i.e., when it's
not been initialized yet after creation or destroyed.
Additionally, `TextControlState::GetValue()` should call
`TextEditor::ComputeTextValue()` if the editor has not been initialized because
it requires the native anonymous subtree to compute the value. I'm not sure
whether this is a bug when `<textarea>` is being initialized.
(I guess that it should get the default value of the text control element or
`mValue` in the case, but we should do that in another bug separately.)
I couldn't find the crash testcase, so, this does not contain a new test.
Differential Revision: https://phabricator.services.mozilla.com/D241543
The anonymous `<div>` of `TextEditor` has only one `Text` as its first child.
Therefore, we can make `TextEditor` simpler to access the `Text` node.
Differential Revision: https://phabricator.services.mozilla.com/D240419
In bug 1940377, `HandleInsertText` will need to normalize surrounding
white-spaces after updating composition string at composition end. To consider
it easier, it's nicer that it takes more detail for the purpose of inserting
text.
Differential Revision: https://phabricator.services.mozilla.com/D239077
This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.
Differential Revision: https://phabricator.services.mozilla.com/D228719
This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.
Differential Revision: https://phabricator.services.mozilla.com/D228719
Now, we have `nsFocusManager::GetFocusedElementStatic()` which returns focused
element if the `nsFocusManager` instance is available. Therefore, if
`nsFocusManager::GetFocusedElement()` users do not use other methods of
`nsFocusManager`, they can use `nsFocusManager::GetFocusedElementStatic()` and
make themselves simpler.
Note that some callers return early if `nsFocusManager` is not available, but
they do not return error and `nsFocusManager` instance is available in most
time of the life time of the process. Therefore, we can simply stop using the
early return.
Differential Revision: https://phabricator.services.mozilla.com/D217527
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
A lone surrogate should not appear in `DOMString` at least when the attribute
values of events because of ill-formed UTF-16 string.
`TextEventDispatcher` does not handle surrogate pairs correctly. It should not
split surrogate pairs when it sets `KeyboardEvent.key` value for avoiding the
problem in some DOM API wrappers, e.g., Rust-running-as-wasm.
On the other hand, `.charCode` is an unsigned long attribute and web apps
may use `String.fromCharCode(event.charCode)` to convert the input to string,
and unfortunately, `fromCharCode` does not support Unicode character code
points over `0xFFFF`. Therefore, we may need to keep dispatching 2 `keypress`
events per surrogate pair for the backward compatibility.
Therefore, this patch creates 2 prefs. One is for using single-keypress
event model and double-keypress event model. The other is for the latter,
whether `.key` value never has ill-formed UTF-16 or it's allowed.
If using the single-keypress event model --this is compatible with Safari and
Chrome in non-Windows platforms--, one `keypress` event is dispatched for
typing a surrogate pair. Then, its `.charCode` is over `0xFFFF` which can
work with `String.fromCodePoint()` instead of `String.fromCharCode()` and
`.key` value is set to simply the surrogate pair (i.e., its length is 2).
If using the double-keypress event model and disallowing ill-formed UTF-16
--this is the new default behavior for both avoiding ill-formed UTF-16 string
creation and keeping backward compatibility with not-maintained web apps using
`String.fromCharCode`--, 2 `keypress` events are dispatched. `.charCode` for
first one is the code of the high-surrogate, but `.key` is the surrogate pair.
Then, `.charCode` for second one is the low-surrogate and `.key` is empty
string. In this mode, `TextEditor` and `HTMLEditor` ignores the second
`keypress`. Therefore, web apps can cancel it only with the first `keypress`,
but it indicates the `keypress` introduces a surrogate pair with `.key`
attribute.
Otherwise, if using the double-keypress event model and allowing ill-formed
UTF-16 --this is the traditional our behavior and compatible with Chrome in
Windows--, 2 `keypress` events are dispatched with same `.charCode` values as
the previous mode, but first `.key` is the high-surrogate and the other's is
the low surrogate. Therefore, web apps can cancel either one of them or
both of them.
Finally, this patch makes `TextEditor` and `HTMLEditor` handle text input
with `keypress` events properly. Except in the last mode, `beforeinput` and
`input` events are fired once and their `data` values are the surrogate pair.
On the other hand, in the last mode, 2 sets of `beforeinput` and `input` are
fired and their `.data` values has only the surrogate so that ill-formed
UTF-16 values.
Note that this patch also fixes an issue on Windows. Windows may send a high
surrogate and a low surrogate with 2 sets of `WM_KEYDOWN` and `WM_KEYUP` whose
virtual keycode is `VK_PACKET` (typically, this occurs with `SendInput` API).
For handling this correctly, this patch changes `NativeKey` class to make it
just store the high surrogate for the first `WM_KEYDOWN` and `WM_KEYUP` and use
it when it'll receive another `WM_KEYDOWN` for a low surrogate.
Differential Revision: https://phabricator.services.mozilla.com/D182142
Before bug 1770874, `EditorBase::OnBlur` checked that for both `TextEditor`
and `HTMLEditor`. However, accidentally, I removed the check from `TextEditor`.
Therefore, a call of `EditorBase::FinalizeSelection()` will hide the caret
even after another editor gets focus.
Therefore, this patch just take it back into `TextEditor::OnBlur`.
Note that I don't think the design mode handling is required there because
`TextEditor`s shouldn't be created in the design mode document.
Differential Revision: https://phabricator.services.mozilla.com/D182468
Currently it runs if the instance is a `TextEditor` or it's in the plaintext
mode of `HTMLEditor`. However, it does not make sense to run it only in
specific mode of `HTMLEditor`, and most part does not make sense for
`HTMLEditor`.
This patch moves the method to `TextEditor`, and for
`EditorBase::InsertTextWithTransaction()` and
`AutoRangeArray::ExtendAnchorFocusRangeFor()`, adds new method to
`EditorDOMPointBase` to get a text node position if it points around
a text node.
Differential Revision: https://phabricator.services.mozilla.com/D181835
This patch makes `EditorBase` implement them as non-virtual methods and
implement their first part. Then, they call new virtual methods to handle
paste and paste-as-quotation.
With this change, `TextEditor` starts to dispatch `paste` event when
paste-as-quotation. The new test checks it.
Differential Revision: https://phabricator.services.mozilla.com/D176739
This patch makes `EditorBase` implement them as non-virtual methods and
implement their first part. Then, they call new virtual methods to handle
paste and paste-as-quotation.
With this change, `TextEditor` starts to dispatch `paste` event when
paste-as-quotation. The new test checks it.
Differential Revision: https://phabricator.services.mozilla.com/D176739
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
It's the only method which is used outside of the editor module. Therefore,
we can stop exposing `EditorUtils.h` later.
Depends on D158634
Differential Revision: https://phabricator.services.mozilla.com/D158635
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
It does different thing for `TextEditor` and `HTMLEditor`, and used almost
internally. Therefore, it should be implemented in the sub classes and
we should name them better.
Differential Revision: https://phabricator.services.mozilla.com/D157407
The method is enough simple, and uses bad cast from point of view of OOP.
Therefore, this patch make the sub classes implement the method only for each.
Differential Revision: https://phabricator.services.mozilla.com/D157406
Masayuki Nakano