Even when execCommand("insertorderedlist") and
execCommand("insertunorderedlist") remove existing lists, we need to set
InputEvent.inputType value to "insertOrderedList" or "insertUnorderedList".
Fortunately, the XPCOM method is used only for handling
execCommand("insertorderedlist") and execCommand("insertunorderedlist") on
Firefox. Therefore, we should make it set EditAction to
EditAction::eRemoveOrderedListElement or EditAction::RemoveUnorderedListElement.
Note that comm-central uses this method directly and uses "cmd_removeList"
which causes calling the XPCOM method with empty string. However, input
events for them won't be exposed to the web. Therefore, it's okay to set
EditAction::eRemoveListElement for the other cases.
Differential Revision: https://phabricator.services.mozilla.com/D11439
--HG--
extra : moz-landing-system : lando
Both Chrome and Safari dispatches 2 sets of "beforeinput" and "input" events
when user drag and drop content in same editor. One is "deleteByDrag" and
the other is "insertFromDrop". We need to follow same behavior since
it should be able to cancel only "deleteByDrag" or "insertFromDrop" when
we implement "beforeinput" event.
HTMLEditor::InsertObject() may handle asynchronously. And we don't need to
do anything additionally for HTMLEditor. Therefore, TextEditor::OnDrop()
can delete selection before inserting dropped content by itself.
Therefore, this patch makes TextEditor::OnDrop() call
TextEditor::PrepareToInsertContent() and EditorBase::FireInputEvent() by
itself.
Unfortunately, it seems that we cannot write automated tests for this.
Even if using synthesizeMouse() of EventUtils, synthesizing mouse events
won't generate "dragover" nor "drop" events. Perhaps, like EventUtils.js,
we need to do something with drag service, but it means that we cannot
emulate drag and drop in an editor.
Differential Revision: https://phabricator.services.mozilla.com/D11285
--HG--
extra : moz-landing-system : lando
Only TextEditor::InsertTextAt() and HTMLEditor::DoInsertHTMLWithContext()
removes selected content before pasting from clipboard or inserting dropped
content, and they do same things. Therefore, they can share the code with
a helper method.
Note that this makes each root caller won't return NS_ERROR_EDITOR_DESTROYED
since the destruction is expected by web app.
Differential Revision: https://phabricator.services.mozilla.com/D11284
--HG--
extra : moz-landing-system : lando
TextEditor::OnDrop() calls TextEditor::InsertFromDataTransfer() or
HTMLEditor::InsertFromDataTransfer() and they are called only by
TextEditor::OnDrop().
TextEditor::InsertFromDataTransfer() calls only TextEditor::InsertTextAt()
and TextEditor::InsertTextAt() calls only TextEditor::InsertTextAsSubAction() if
insertion point is nullptr. Therefore, if the callers sets nullptr, they
should call TextEditor::InsertTextAsSubAction() directly. Then, we can
make TextEditor::InsertTextAt() require non-nullptr insertion point.
HTMLEditor::InsertFromDataTransfer() calls HTMLEditor::InsertObject(),
HTMLEditor::DoInsertHTMLWithContext() or TextEditor::InsertTextAt().
HTMLEditor::InsertObject() calls HTMLEditor::DoInsertHTMLWithContext()
directly or via BlobReader (in this case, calls asynchronously).
Unfortunately both HTMLEditor::InsertObject() and
HTMLEditor::DoInsertHTMLWithContext() are called by
HTMLEditor::InsertFromTransferable() which is paste event handler. Therefore,
we cannot make them require non-nullptr insertion point, though, anyway,
they cannot become simpler even if we could do that.
This patch marks them as MOZ_CAN_RUN_SCRIPT as far as possible and
makes them take |const EditorDOMPoint&| for insertion point.
Differential Revision: https://phabricator.services.mozilla.com/D11283
--HG--
extra : moz-landing-system : lando
When Selection is NOT collapsed, we remove selected content. Therefore,
web apps don't need to know range information of user operation. However, web
apps may want to know direction of the operation (backward or forward). E.g.,
web apps may just mark selected range as "deleted" and move caret before or
after the range.
Therefore, when computed EditAction is eDeleteWordBackward or
eDeleteToBeginningOfSoftLine, we should use eDeleteBackward instead. When it
is eDeleteWordForward or eDeleteToEndOfSoftLine, we should use eDeleteForward
instead.
Note that only on Windows, we follow behavior of richtext control (and Word).
That is, Ctrl + Backspace/Delete collapse from start of selected range to
start/end of current word. I.e., collapsing Selection to start first and
removing to start or end of current word is Windows's standard behavior.
Currently, we do this in DeleteSelectionAsSubAction() but every caller
specifies eNone to aDirection except DeleteSelectionAsAction(). So, we can
move this before re-computing EditAction in DeleteSelectionAsAction().
Differential Revision: https://phabricator.services.mozilla.com/D10992
--HG--
extra : moz-landing-system : lando
No one uses nsISpellChecker, so let's get rid of nsISpellChecker.
Depends on D10993
Differential Revision: https://phabricator.services.mozilla.com/D10994
--HG--
extra : moz-landing-system : lando
When creating an instance of nsISpellChecker, we always use
mozSpellChecker::Create. So we should use mozSpellChecker directly instead of
nsISpellChecker.
Differential Revision: https://phabricator.services.mozilla.com/D10993
--HG--
extra : moz-landing-system : lando
ResizerMouseMotionListener listens to "mousemove" events for resizers
or grabber to move absolutely position element and it calls only
HTMLEditor::MouseMove(). Fortunately, neither EditorEventListener not
HTMLEditorEventListener listens to "mousemove" events. Therefore, we
can use HTMLEditorEventListener instead.
Differential Revision: https://phabricator.services.mozilla.com/D10869
--HG--
extra : moz-landing-system : lando
DocumentResizeEventListener listens to only "resize" events of the window
and when it fired, it just calls HTMLEditor::RefreshResizers(). Fortunately,
neither EditorEventListener nor HTMLEditorEventListener listens to "resize"
events. Therefore, we can move this implementation into
HTMLEditorEventListener.
Differential Revision: https://phabricator.services.mozilla.com/D10866
--HG--
extra : moz-landing-system : lando
No one uses nsISpellChecker, so let's get rid of nsISpellChecker.
Differential Revision: https://phabricator.services.mozilla.com/D10994
--HG--
extra : rebase_source : 1caeba2edf7677258c0406f087eaa41e12cbb8a8
extra : histedit_source : 6a90572e8ecddf0f13fbe5b1abf1bedf1c84a4d9
When creating an instance of nsISpellChecker, we always use
mozSpellChecker::Create. So we should use mozSpellChecker directly instead of
nsISpellChecker.
Differential Revision: https://phabricator.services.mozilla.com/D10993
--HG--
extra : rebase_source : 0feffa60e6dc788904d212a77acbf416279af083
extra : histedit_source : b89cc8270c2df70ae414479f43ac30e8aa0a3d42
This fixes odd case of this API. GetSelectedElement() ignores non-element
nodes before an element node. This must be intended to allow Selection to
start from in an element node. However, current code allows to select starting
from previous text node. This patch changes this behavior to stop looking
for element node if non-element node appears before an element node.
Differential Revision: https://phabricator.services.mozilla.com/D10703
--HG--
extra : moz-landing-system : lando
The |for| loop in HTMLEditor::GetSelectedElement() does not allow to be
after an element node because if another element is found, returns nullptr,
and if another non-element node is found, lastElementInRange which is
result of the method is cleared. So, we checking lastElementInRange at
first of the for loop (i.e., immediately after calling
nsIContentIterator::Next()), we can get rid of use ugly bool flag.
Differential Revision: https://phabricator.services.mozilla.com/D10702
--HG--
extra : moz-landing-system : lando
HTMLEditor::GetSelectedElement() uses |while| and calls
nsIContentIterator::Next() at the last line. Therefore, it cannot use
early-continue style. Because nsIContentIterator::Next() is always called,
it should be rewrite with |for|.
Differential Revision: https://phabricator.services.mozilla.com/D10701
--HG--
extra : moz-landing-system : lando
HTMLEditor::GetSelectedElement() should use RangeBoundary to reduce auto
variables which are in large scope. So, first optimization block can be
optimized with RangeBoundary.
Then, the second block, for handling nsGkAtoms::href, does not need to
retrieve AnchorRef() nor FocusRef() since this is exactly same as
StartRef() and EndRef() of the first range when there is only one selected
range. So, the last |if| block in this block is not necessary since
this has already been handled by the first block.
Differential Revision: https://phabricator.services.mozilla.com/D10700
--HG--
extra : moz-landing-system : lando
HTMLEditor::GetElementOrParentByTagNameInternal() may return <a> element
which does not match for nsGkAtoms::href or nsGkAtoms::anchor (in the former
case, it should return only an <a> element which has "href" attribute and
its value is not empty. in the latter case, it should return only <a> element
which has "name" attribute and its value is not empty).
This patch makes it won't check found element's name when nsGkAtoms::href or
nsGkAtoms::anchor is specified.
Differential Revision: https://phabricator.services.mozilla.com/D10699
--HG--
extra : moz-landing-system : lando
This takes back old behavior, 59 or earlier version.
|selectedElement| may be set to an element which is not what the caller is
looking for. Therefore, if the first element node in the selected range is
not what the caller is looking for, it should return nullptr.
This regression is caused by this changeset:
https://hg.mozilla.org/mozilla-central/rev/93c1d149d757 (bug 1432944)
Additionally, this patch modifies the automated test for conforming to
original idea of the API. This API must not be intended to retrieve
usual inline elements like <b>, <i>, etc.
Differential Revision: https://phabricator.services.mozilla.com/D10697
--HG--
extra : moz-landing-system : lando
DocumentResizeEventListener::HandleEvent() calls protected method,
HTMLEditor::RefreshResizersInternal(). However, this method is an event
handler, i.e., called when the editor is not handling an edit action.
Therefore, for ensuring AutoEditActionDataSetter instance, it should call
public method, nsIHTMLEditor::RefereshResizers() instead.
Differential Revision: https://phabricator.services.mozilla.com/D10706
--HG--
extra : moz-landing-system : lando
HTMLEditor::BlobReader::OnResult() is a callback method and it calls
non-public method of HTMLEditor, DoInsertHTMLWithContext(). So,
DoInsertHTMLWithContext() may need caller to have already created
AutoEditActionDataSetter instance. Therefore, BlobReader should keep
EditAction which is the purpose of creating it and its OnResult() should
create AutoEditActionDataSetter instance with it.
Differential Revision: https://phabricator.services.mozilla.com/D10532
--HG--
extra : moz-landing-system : lando
Now, TextEditor needs only InsertLineBreak*() so that
InsertParagraphSeparator*() is necessary only in HTMLEditor.
With overriding nsIPlaintextEditor::InsertLineBreak() in HTMLEditor,
we can do it simply.
Differential Revision: https://phabricator.services.mozilla.com/D10525
--HG--
extra : moz-landing-system : lando
This patch creates new path to insert a line break in TextEditor.
Declares new EditSubAction::eInsertLineBreak and makes the path use
EditAction::eInsertLineBreak instead of EditAction::eInsertParagraphSeparator.
Unfortunately, this patch makes TextEditor::InsertLineBreakAsAction() as
a virtual method for keeping this change as small as possible.
Differential Revision: https://phabricator.services.mozilla.com/D10524
--HG--
extra : moz-landing-system : lando
When TextEditRules::WillDoAction() and HTMLEditRules::WillDoAction() didn't
return error, didn't handle it, and didn't cancel it,
TextEditor::InsertParagraphSeparatorAsSubAction() inserts a line breaker.
However, this case is only when the instance is TextEditRules and
TextEditRules::WillInsertLineBreak() prepares to insert a line break without
any errors. So, we can move the part into TextEditRules::WillInsertLineBreak()
simply.
Differential Revision: https://phabricator.services.mozilla.com/D10523
--HG--
extra : moz-landing-system : lando
With this cleaning up, we can know when they return NS_OK with both
aCanceled is false and aHandled is false. (Look for EditActionIgnored().)
Additionally, this patch renames HTMLEditRules::WillInsertBreak() to
WillInsertParagraphSeparator() and TextEditRules::WillInsertBreak() to
TextEditRules::WillInsertLineBreak().
Differential Revision: https://phabricator.services.mozilla.com/D10522
--HG--
extra : moz-landing-system : lando
TextEditor::OnInputParagraphSeparator() and HTMLEditor::OnInputLineBreak() are
also used by command handlers. Therefore, they should be renamed to
TextEditor::InsertParagraphSeparatorAsAction() and
HTMLEditor::InsertLineBreakAsAction(). Then, current
TextEditor::InsertParagraphSeparatorAsAction() should be renamed to
AsSubAction() and each caller of it should create AutoPlaceholderBatch
by themselves.
Differential Revision: https://phabricator.services.mozilla.com/D10521
--HG--
extra : moz-landing-system : lando
Now, TextEditor needs only InsertLineBreak*() so that
InsertParagraphSeparator*() is necessary only in HTMLEditor.
With overriding nsIPlaintextEditor::InsertLineBreak() in HTMLEditor,
we can do it simply.
Differential Revision: https://phabricator.services.mozilla.com/D10525
--HG--
extra : moz-landing-system : lando
This patch creates new path to insert a line break in TextEditor.
Declares new EditSubAction::eInsertLineBreak and makes the path use
EditAction::eInsertLineBreak instead of EditAction::eInsertParagraphSeparator.
Unfortunately, this patch makes TextEditor::InsertLineBreakAsAction() as
a virtual method for keeping this change as small as possible.
Differential Revision: https://phabricator.services.mozilla.com/D10524
--HG--
extra : moz-landing-system : lando
When TextEditRules::WillDoAction() and HTMLEditRules::WillDoAction() didn't
return error, didn't handle it, and didn't cancel it,
TextEditor::InsertParagraphSeparatorAsSubAction() inserts a line breaker.
However, this case is only when the instance is TextEditRules and
TextEditRules::WillInsertLineBreak() prepares to insert a line break without
any errors. So, we can move the part into TextEditRules::WillInsertLineBreak()
simply.
Differential Revision: https://phabricator.services.mozilla.com/D10523
--HG--
extra : moz-landing-system : lando
With this cleaning up, we can know when they return NS_OK with both
aCanceled is false and aHandled is false. (Look for EditActionIgnored().)
Additionally, this patch renames HTMLEditRules::WillInsertBreak() to
WillInsertParagraphSeparator() and TextEditRules::WillInsertBreak() to
TextEditRules::WillInsertLineBreak().
Differential Revision: https://phabricator.services.mozilla.com/D10522
--HG--
extra : moz-landing-system : lando
TextEditor::OnInputParagraphSeparator() and HTMLEditor::OnInputLineBreak() are
also used by command handlers. Therefore, they should be renamed to
TextEditor::InsertParagraphSeparatorAsAction() and
HTMLEditor::InsertLineBreakAsAction(). Then, current
TextEditor::InsertParagraphSeparatorAsAction() should be renamed to
AsSubAction() and each caller of it should create AutoPlaceholderBatch
by themselves.
Differential Revision: https://phabricator.services.mozilla.com/D10521
--HG--
extra : moz-landing-system : lando
Since reftest doesn't access clipboard, this test is implemented by mochitest
even if this compares with image.
Differential Revision: https://phabricator.services.mozilla.com/D10531
--HG--
extra : rebase_source : ef7bd6cc081ee5b5b821fdcef24b1c20c5315f49
When inputting any character in password field, character isn't masked
immediately since echo password is turned on Android. But when pasting text,
the text is masked immediately on Blink and Android OS.
So we should adopt this behaviour on Gecko too.
Differential Revision: https://phabricator.services.mozilla.com/D10530
--HG--
extra : rebase_source : b4bc026569e61fee697cb538719216fb258a11ae
Input Events Level 2 declares "deleteByComposition" for empty composition
removes selected content and "deleteCompositionText" for canceling composition.
https://w3c.github.io/input-events/#interface-InputEvent-Attributes
Therefore, TextEditor::OnCompositionChange() should use a new EditAction for
the former only when new composition string is empty, there is no composition
string and there is non-collapsed Selection.
And also TextEditor::OnCompositionEnd() should use another new EditAction for
the latter when composition is canceled with empty string (we don't restore
selected content which is removed by the composition).
Additionally, due to bug 1305387, we don't dispatch "input" event when
we handle TextEditor::OnCompositionChange(). Instead, we dispatch it
when we handle TextEditor::OnCompositionEnd(). Therefore, we need to
use EditAction::eCommitComposition in TextEditor::OnCompositionEnd().
Differential Revision: https://phabricator.services.mozilla.com/D10520
--HG--
extra : moz-landing-system : lando
Now, any protected/private methods of editor classes can refer
SelectionRefPtr() safely. So, we can cut the cost of calling GetSelection()
only once per edit action handling.
Differential Revision: https://phabricator.services.mozilla.com/D10011
--HG--
extra : moz-landing-system : lando
When each method of TextEditRules and HTMLEditRules should be called only by
EditorBase/TextEditor/HTMLEditor while the editor instance has
AutoEditActionDataSetter instance. Therefore, we can get rid of all
pointers/references of Selection from each method's argument.
Additionally, this reimplements TextEditRules::SelectionRef() with
EditorBase::SelectionRefPtr() and make it return |const RefPtr<Selection>&|
rather than |Selection&| since RefPtr reference is required when we call
methods which are marked as MOZ_CAN_RUN_SCRIPT.
Differential Revision: https://phabricator.services.mozilla.com/D10010
--HG--
extra : moz-landing-system : lando
Geoff Brown
Masayuki Nakano
Csoregi Natalia
Dorel Luca
Makoto Kato
Gurzau Raul
Ehsan Akhgari
Cosmin Sabou
Ciure Andrei
Tom Schuster
Edgar Chen
Gabriele Svelto