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
`AutoRangeArray` is created for making some handlers of the editor classes free
from `Selection` and `nsFrameSelection` while handling the edit actions.
However, the method still depends on `nsFrameSelection` instance since its
callees are instance methods of `nsFrameSelection`.
However, `EditContext` requires completely free methods to compute target
ranges of `beforeinput`. Therefore, we need to make it not depend on
`Selection` nor `nsFrameSelection`.
The common method, `nsFrameSelection::CreateRangeExtendedToSomewhere`, requires
`PresShell`, selection limiter which is set only when the selection is an
independent selection like in a selection for a text control, selection
ancestor limiter which is set only when an editing host has focus, caret
association hint to put caret to end of preceding line or start of following
line if selection range is collapsed at a line break and caret bidi level for
considering caret position around line break in bidi text. They are now stored
by `nsFrameSelection` and modified when selection range is changed in some
cases. Basically, the method is called without updating its ranges and if and
only if it's initialized with `Selection`. So, simply caching the
`nsFrameSelection`'s values solves the issues in the most cases, but this
patch makes `AutoRangeArray` adjust the value only when its `Collapse` is
called because `Selection` automatically updates it and we can compute the
value without `Selection` nor `nsFrameSelection`.
After applying this patch, `AutoRangeArray` has two meanings, one is the
instance is a proxy for `Selection`. The other is a container for a range to
call methods which take pointer or reference to it. To make this differences
checked at build time, this patch creates a new subclass of it, and renamed to
`AutoClonedRangeArray` to make it clearer that what are stored in the array.
Oddly, `AutoRangeArray(nsRange&)` constructor has not been cloned. Therefore,
I make it and its subclass version clone before storing into the array. Then,
one caller needs to change which range should be tracked.
Differential Revision: https://phabricator.services.mozilla.com/D232174
Both Chrome and Safari clean up unnecessary padding line breaks when they become
unnecessary. Therefore, we should follow that.
Differential Revision: https://phabricator.services.mozilla.com/D225038
Both Chrome and Safari clean up unnecessary padding line breaks when they become
unnecessary. Therefore, we should follow that.
Differential Revision: https://phabricator.services.mozilla.com/D225038
The backed-out patch is Bug 1923251 (part 1).
This does not backout the changes in `EditorDOMPoint.h`, `WSRunObject.h` and
template method instantiation in `WSRunObject.cpp` to make some other my local
changes keep working. (They won't affect to any behavior.)
Depends on D226631
Differential Revision: https://phabricator.services.mozilla.com/D226632
Both Chrome and Safari clean up unnecessary padding line breaks when they become
unnecessary. Therefore, we should follow that.
Differential Revision: https://phabricator.services.mozilla.com/D225038
Both Chrome and Safari clean up unnecessary padding line breaks when they become
unnecessary. Therefore, we should follow that.
Differential Revision: https://phabricator.services.mozilla.com/D225038
The handler has an early-return block for the case inserting empty text.
However, it's done before deleting selection, but it should be done after that.
Differential Revision: https://phabricator.services.mozilla.com/D190904
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
And also this patch makes its only user,
`EditorBase::InsertTextIntoTextNodeWithTransaction`, and its only caller,
`EditorBase::InsertTextWithTransaction`, return `InsertTextResult` for
returning both end of inserted text and caret point suggestion. Note that
if it's for IME composition, `CompositionTransaction` needs to update
`Selection` directly. Therefore, caret point may be unset under composition
to updating `Selection` to wrong point (it seems that
`TextEditor::HandleInsertText` can be simplified later because of this change).
Depends on D169044
Differential Revision: https://phabricator.services.mozilla.com/D169744
nsISupports.h includes nsISupportsBase.h, so it should be equivalent.
In the next patch, I'm changing things so that nsISupports is defined in
nsISupports.h instead of nsISupportsBase.h, and deleting the latter, so
this change will be needed anyways. I'm guessing people were using IWYU
or something like that.
Differential Revision: https://phabricator.services.mozilla.com/D159169
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
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
In theory, methods which touch the DOM tree should take `EditorDOMPoint` rather
than `EditorRawDOMPoint`. And now, we can return meaningful value if it
succeeded, with `Result`.
Therefore, this patch makes it return `Result<EditorDOMPoint, nsresult>` instead
of taking an out argument, and take only `EditorDOMPoint` rather than taking any
type of `EditorDOMPointBase` since it's always converted to `EditorDOMPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D143881
To avoid the unnecessary conversion between `EditorDOMPoint` and
`EditorRawDOMPoint`, it should be a template method which can take/return either
`EditorDOMPoint` or `EditorRawDOMPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D143880
First, move methods of `HTMLEditor` which collapse `Selection` to `EditorBase`.
Then, make editor stop accessing `Selection::CollapseInLimiter` directly.
Differential Revision: https://phabricator.services.mozilla.com/D143814
It's hard to remember what the `bool` value of them means. Therefore, there
are a lot of comment around the API users to explain what they do. For making
it clearer and reducing the risk of specifying opposite value, they should work
with an `enum class`.
Differential Revision: https://phabricator.services.mozilla.com/D143812
They return IME selection range rather than composition string range. I.e.,
when the composition does not have IME selections anymore, e.g., at committing,
they return non-set `RawRangeBoundary`.
For making the result meaning clearer, they should be
`FirstIMESelectionStartRef` and `LastIMESelectionEndRef`.
Depends on D141194
Differential Revision: https://phabricator.services.mozilla.com/D141195
Our internal code can touch internal `Selection` object of `<input>` and
`<textarea>`, thus, selection ranges in them may be not in the text node.
Therefore, we should make `TextEditor` instance try to shrink the deleting
ranges into the text node first.
In a followup bug (perhaps, bug 1734846), we should split the deletion code into
`TextEditor` and `HTMLEditor` for making the code simpler and never regressed.
Differential Revision: https://phabricator.services.mozilla.com/D133181
Similar to the previous patch, this patch makes `insertLineBreak` command
handler of `HTMLEditor` may insert a linefeed character instead of `<br>`
element for compatibility with Blink/WebKit.
Note that for making same name rules as `insertParagraphSeparator` command
handlers, this patch renames
`HTMLEditor::InsertBRElementAtSelectionWithTransaction()` to
`InsertLineBreakAsSubAction()` and moves
`EditorBase::InsertLineBreakAsSubAction()` to `TextEditor` since it's
used only by `TextEditor` instance.
Depends on D124731
Differential Revision: https://phabricator.services.mozilla.com/D124732
Web apps can modify normal selection even during IME composition and no
browsers stop composition by it. However, our editor tries to delete
non-collapsed selected range before updating composition. Therefore,
we need additional state at handling inserting text whether selection
should be deleted or ignored.
Depends on D121371
Differential Revision: https://phabricator.services.mozilla.com/D121372
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
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
Sylvestre Ledru