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
EditorBase::SelectionRefPtr() is now safe to use in editor and really fast to
retrieve Selection than EditorBase::GetSelection(). Therefore, we can get rid of
all Selection pointer/reference argument of each method which always take
normal Selection.
Note that this changes nsIHTMLEditor.checkSelectionStateForAnonymousButtons()
because its argument is only Selection. So, BlueGriffon should work even
though it calls the method with nsIEditor.selection.
Differential Revision: https://phabricator.services.mozilla.com/D10009
--HG--
extra : moz-landing-system : lando
This patch makes public methods of EditorBase create AutoEditActionDataSetter
as far as possible. However, does not do so for some public methods if they are
not necessary to create it.
Differential Revision: https://phabricator.services.mozilla.com/D10006
--HG--
extra : moz-landing-system : lando
Like TextEditRules, EditorBase should have a stack class which cache necessary
objects and current handling edit action. The edit action will be necessary
when we implement InputEvent.inputType.
Different from TextEditRules, this adds |const RefPtr<Selection>&| instead
of |Selection&|. The reason is, when I add MOZ_CAN_RUN_SCRIPT to some methods,
it's not allowed like this:
> foo->CanRunScriptMethod(SelectionRef());
I'll update TextEditRules for consistency in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D10005
--HG--
extra : moz-landing-system : lando
Since bug 1491173 is landed, there is no users of dumpContentTree,
debugDumpContent and debugUnitTests. So Let's remove these methods from
nsIEditor.
Differential Revision: https://phabricator.services.mozilla.com/D10029
--HG--
extra : moz-landing-system : lando
Regression of bug 1476897, HTMLEditor::InsertAsPlaintextQuotation() refers
|newNode| which is new created <span> element by the method at collapsing
Selection. However, it's already been moved to its out param. Therefore,
after the fix of bug 1476897, it won't collapse Selection. This patch
moves the code moving |newNode| to the out param after collapsing Selection.
Additionally, this makes HTMLEditor::InsertAsCitedQuotationInternal() use
same style code around collapsing Selection since it's also tested by the
new test of nsIEditorMailSupport.insertAsCitedQuotation().
Differential Revision: https://phabricator.services.mozilla.com/D10002
--HG--
extra : moz-landing-system : lando
HTMLEditRules::DocumentModifiedWorker() may be called asynchronously via
AddScriptRunnder. Therefore, this may not be in the stack while editor handles
an edit action. Then, HTMLEditRules cannot access edit action data which will
be put on the stack after fixing bug 1465702. So, it should do it after once
calling a method of editor instance (and editor instance should call back
proper HTMLEditRules method).
Differential Revision: https://phabricator.services.mozilla.com/D9536
--HG--
extra : moz-landing-system : lando
TextEditRules::Notify() is callback of the timer. Therefore, this won't be
in the stack while editor handles an edit action. Then, TextEditRules
cannot access edit action data which will be put on the stack after fixing
bug 1465702. So, it should do it after once calling a method of editor
instance (and editor instance should call back proper TextEditRules method).
Differential Revision: https://phabricator.services.mozilla.com/D9502
--HG--
extra : moz-landing-system : lando
HTMLEditor::InsertAsCitedQuotation() is an XPCOM method, so, it shouldn't be
used for internal use. Instead, there should be non-virtual method and
InsertAsCitedQuotation() should use it.
Differential Revision: https://phabricator.services.mozilla.com/D9501
--HG--
extra : moz-landing-system : lando
AutoTransactionBatch, AutoPlaceholderBatch, AutoSelectionRestorer,
AutoTopLevelEditSubActionNotifier, AutoTransactionsConserveSelection and
AutoUpdateViewBatch access protected members of EditorBase. The access
scope management assume that they are used only by EditorBase or its
subclasses or TextEditRules or its inherited class (i.e., HTMLEditRules).
For guaranteeing this at build-time, we should change them to nested classes
of EditorBase. Then, EditorBase and its subclasses and friends can use them.
Differential Revision: https://phabricator.services.mozilla.com/D9479
--HG--
extra : moz-landing-system : lando
Unfortunately, TextServicesDocument::InsertText() is too complicated to
do it with both editor class and TextServicesDocument separately.
Therefore, this patch adds AutoTransactionBatchExternal class which is
almost same as AutoTransactionBatch but uses XPCOM methods to begin/end
transaction. This change helps editor to manage whether it starts to
handle new edit action or not when BeginTransaction() is called explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9478
--HG--
extra : moz-landing-system : lando
StyleUpdatingCommand::ToggleState() removes exclusive style when it sets
superscript style or subscript style. However, it accesses protected
members of EditorBase via AutoTransactionBatch even though it's outside
of editor classes.
This patch moves the removing exclusive style code from the method to
HTMLEditor::SetInlineProperty() and rename it "AsAction".
Differential Revision: https://phabricator.services.mozilla.com/D9477
--HG--
extra : moz-landing-system : lando
Depends on D8739.
This changeset updates calls to ok() that were most likely intended
for is(), but are not working as is.
Differential Revision: https://phabricator.services.mozilla.com/D8740
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
A lot of loops in HTMLTableEditor.cpp scans cells along column-axis or
row-axis. In those cases, they need to skip columns/rows which are spanned
from prior column/row. So, we can rewrite them with CellData::NextColumnIndex()
or CellData::NextRowColumn().
Differential Revision: https://phabricator.services.mozilla.com/D8358
--HG--
extra : moz-landing-system : lando
This patch makes all nsITableEditor::GetCellDataAt() use CellData, and if
each caller checks the result of GetCellDataAt() with NS_FAILED(), this
replaces it with CellData::FailedOrNotFound() since GetCellDataAt() returns
error even when it does not find a cell element. Finally, copies each
CellData member to the variable which received corresponding value from
GetCellDataAt() for making this change safe. Note that for easier to review,
the copying blocks have odd indent. Those variables will be removed or
corrected the indent by the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D8339
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetCellDataAt() is an XPCOM method but used internally a lot.
Additionally, it scatters a lot of variables (including unused) since it takes
a lot of out arguments to return. Therefore, this should be implemented as
struct and users should refer each member as result.
This does not replaces the callers yet since it's too risky if the caller is
not tested by automated test. Following patches will replace the method call
and each variable step by step.
Differential Revision: https://phabricator.services.mozilla.com/D8338
--HG--
extra : moz-landing-system : lando
This patch makes EventStateManager handle middle click paste as a default
action.
Unfortunately, we cannot remove the call of HandleMiddleClickPaste() in
EditorEventListener because it's important to consume middle click event
before any elements in the editor. For example, if clicked HTMLEditor has
non-editable <a href> element, middle click event needs to be handled by the
editor rather than contentAreaUtils which handles click events of <a href>
elements. The cause of this kind of issues is, any click event handlers
which handle non-primary button events still listen to "click" events.
Therefore, this patch makes HandleMiddleClickPaste() do nothing if the mouseup
event is fired on an editor.
Differential Revision: https://phabricator.services.mozilla.com/D7855
--HG--
extra : moz-landing-system : lando
This is preparation of the last patch. Even if no editor is clicked with
middle button, we need to do:
- collapse Selection at the clicked point.
- dispatch "paste" event.
Therefore, HandleMiddleClickPaste() should dispatch ePaste event by itself
and each editor methods should have a bool argument which the caller wants
ePaste event automatically.
Note that Chromium dispatches "paste" event and pastes clipboard content
into clicked editor even if preceding "auxclick" event is consumed.
However, our traditional behavior is not dispatching "paste" event nor
pasting clipboard content. Unless Chromium developer keeps their odd
behavior, we should keep our traditional behavior since our behavior is
conforming to DOM event model.
Differential Revision: https://phabricator.services.mozilla.com/D7854
--HG--
extra : moz-landing-system : lando
The event argument of only EditorEventListener::MouseClick() can be replaced
with WidgetMouseEvent simply. So, for avoiding unnecessary RefPtr in
EditorEventListener::HandleEvent(), we should fix this now.
Differential Revision: https://phabricator.services.mozilla.com/D7853
--HG--
extra : moz-landing-system : lando
EventStateManager needs to handle middle click paste without editor.
Therefore, the handler should be in EventStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D7852
--HG--
extra : moz-landing-system : lando
We need to move EditorEventListener::HandleMiddleClickPaste() into
EventStateManager to handle middle click paste after all click events are
dispatched. This is preparation of the change.
HandleMiddleClickPaste() uses UIEvent::GetRangeParent() and
UIEvent::RangeOffset() to collapse Selection at clicked point. However,
EventStateManager cannot access them since EventStateManager can handle it
with WidgetMouseEvent. Fortunately, only WidgetMouseEvent is necessary for
implementing them. Therefore, we can move the implementation into
nsLayoutUtils and merge them.
Differential Revision: https://phabricator.services.mozilla.com/D7851
--HG--
extra : moz-landing-system : lando
The ancestor limiter is set by focus event handler of editor. But window that
is run script has no focus, this event isn't fired by addRange etc.
Some execCommand's commands such as 'forwardDelete' uses WillDeleteSelection
then selection for deletion is set by selection controller (in
TextEditor::ExtendSelectionForDelete). So, due to no ancestor limiter, caret
(and any for delete commands such as CharacterExtendForDelete) can move to out
of editor's root.
So we should set ancestor limiter if nothing. If focus event is received by
user interaction etc, limiter will be set again.
Differential Revision: https://phabricator.services.mozilla.com/D6374
--HG--
extra : rebase_source : 240c3bc09b37d46d1ce3245bcca55cafc59454c5
FindSelectionRoot isn't const method and returns already_AddRefed<nsIContent>.
But this method doesn't modify any members and nodes, so we can change to const
method
Also, this method already returns Element, so it shouldn't return nsIContent.
Differential Revision: https://phabricator.services.mozilla.com/D6373
--HG--
extra : rebase_source : d4a5dbe96dfc0a71b39f3d5c6d1a4c7ce85f4fa9
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
nsITableEditor::InsertTableCell() is an XPCOM method but used internally. So,
HTMLEditor should implement it with a non-virtual method and all internal users
should use it instead.
Differential Revision: https://phabricator.services.mozilla.com/D6259
--HG--
extra : moz-landing-system : lando
nsITableEditor::InsertTableColumn() is an XPCOM method but it's used internally.
So, HTMLEditor should implement it with a non-virtual method and internal
users should use it instead.
Differential Revision: https://phabricator.services.mozilla.com/D6257
--HG--
extra : moz-landing-system : lando
nsITableEditor::InsertTableRow() is an XPCOM method but there are some internal
users. So, HTMLEditor should implement it with a non-virtual method and
it should be used by all internal users.
Differential Revision: https://phabricator.services.mozilla.com/D6179
--HG--
extra : moz-landing-system : lando
HTMLEditor::DeleteTableCellWithTransaction() does not remove <table> element
even if it becomes empty only when 2 or more cell elements are selected.
Therefore, we should check table size before removing a row and if it's the
last row, the method should remove <table>.
Differential Revision: https://phabricator.services.mozilla.com/D6177
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableCell() is an XPCOM method but used internally.
So, HTMLEditor should implement it with non-virtual method and use it
internally.
Differential Revision: https://phabricator.services.mozilla.com/D6176
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableCellContents() is an XPCOM method but it's used
internally. So, HTMLEditor should implement it with a non-virtual method
and all internal users should use the non-virtual method instead.
This patch adds HTMLEditor::DeleteTableCellContentsWithTransaction() for that.
Additionally, this patch renames its helper method DeleteCellContents() to
DeleteAllChidlrenWithTransaction() and moves it to HTMLEditor.cpp since it can
handle any element nodes.
Differential Revision: https://phabricator.services.mozilla.com/D6174
--HG--
extra : moz-landing-system : lando
This patch renames HTMLEditor::DeleteColumn() to
HTMLEditor::DeleteTableColumnWithTransaction() and cleans up its implementation.
Differential Revision: https://phabricator.services.mozilla.com/D5934
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableColumn() is an XPCOM method but used internally.
So, it should be implemented with non-virtual method and internal users
should use it.
Note that this changes only one thing. This moves
|AutoTopLevelEditSubActionNotifier maybeTopLevelEditSubAction(...| from
below DeleteTableElementAndChildrenWithTransaction() to above it.
I.e., DeleteTableElementAndChildrenWithTransaction() works under
EditSubAction::eDeleteNode as the top level sub-action now. This is same
as DeleteSelectedTableRowsWithTransaction(). Therefore, the difference
with it when it removes <table> is now fixed.
Differential Revision: https://phabricator.services.mozilla.com/D5933
--HG--
extra : moz-landing-system : lando
This add automated tests for nsITableEditor.deleteTableColumn().
However, this contains some fixes of existing code since with those bugs,
the test isn't passed even in the simplest case.
Differential Revision: https://phabricator.services.mozilla.com/D5932
--HG--
extra : moz-landing-system : lando
This patch renames HTMLEditor::DeleteRow() to
HTMLEditor::DeleteTableRowWithTransaction() and cleans up its implementation.
Differential Revision: https://phabricator.services.mozilla.com/D5931
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableRow() is an XPCOM method but there are some internal
users. So, it should be implemented as non-virtual protected method and
internal users should use it instead.
This also renames (and reimplement) HTMLEditor::DeleteTable2() since it's
really bad name and the code dispatches unnecessary "selectionchange" events.
Differential Revision: https://phabricator.services.mozilla.com/D5930
--HG--
extra : moz-landing-system : lando
This patch changes a bit in HTMLEditor::DeleteTableRow() because calling
DeleteTable2() without those helper classes hits MOZ_ASSERT().
Differential Revision: https://phabricator.services.mozilla.com/D5929
--HG--
extra : moz-landing-system : lando
Since I have landed bug 1489939, comm-central only uses rewrap method in
nsIEditorMailSupport. And insertAsCitedQuotation is used by the test of
editor/libeditor/tests/test_bug616590.xul.
Other methods are unused now, so let's remove these from nsIEditorMailSupprt,
and move it to HTMLEditor. Also, pasteAsQuotation is unused now even if
BlueGriffon.
Differential Revision: https://phabricator.services.mozilla.com/D5835
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetSelectedOrParentTableElement() is of course an XPCOM method,
but it's used internally. So, there should be non-virtual method.
On the other hand, this API is too ugly. Returns various information but each
meaning is not clear. So, result of the new non-virtual method should be
simpler.
This patch creates the new method as:
- returns found element
- takes ErrorResult to return error code.
- takes optional out-param for returning if a cell is selected.
Then, nsITableEditor::GetSelectedOrParentTableElement() can compute its
result from them with Selection.
Differential Revision: https://phabricator.services.mozilla.com/D5728
--HG--
extra : moz-landing-system : lando
If a cell element and its indexes in the <table> are stored in a struct,
it makes the user methods easier to read. Therefore, this patch implement
such struct as HTMLEditor::CellAndIndexes and make it finds first selected
cell and indexes with its method. Finally, this reimplement
HTMLEditor::GetFirstSelectedCellInTable() with it.
Differential Revision: https://phabricator.services.mozilla.com/D5664
--HG--
extra : moz-landing-system : lando
This adds automated tests for nsITableEditor.getFirstSelectedCellInTable().
However, this test crashes due to regression of bug 1484128. So, we need
to uplift only this fix into the Beta.
Differential Revision: https://phabricator.services.mozilla.com/D5663
--HG--
extra : moz-landing-system : lando
I tried to create automated tests for nsITableEditor::NormalizeTable().
However, this method cannot normalize any broken table element. The method
always returns error after calling HTMLEditor::FixBadRowSpan(). The reason
is that HTMLEditor::FixBadRowSpan() scans all cells in each row with a for
loop, and then, when it fails to find a cell element, it returns error even
though this method needs to fix the odd situation. According to the history
of editor changes, each important point hasn't been changed since first
implementation. So, perhaps, table layout API behavior was changed but
no automated tests couldn't detect the regression since we really don't have
enough tests for editor.
Anyway, this patch makes most part of nsITableEditor::NormalizeTable() with
non-virtual method, HTMLEditor::NormalizeTable().
Differential Revision: https://phabricator.services.mozilla.com/D5633
--HG--
extra : moz-landing-system : lando
When I added some tests into test_middle_click_paste.html, I realized that
SimpleTest.waitForClipboard() in copyHTMLContent() fails to copy the
HTML fragment to clipboard and just quit the test. Therefore, only the
last tests are ignored always.
The reason is, iframe.contentDocument.getSelection() returns nullptr
since the frame becomes visible immediately before accessing the Selection.
This patch makes flushing the pending layout with scrollTop. This makes
getSelection() return non-null.
However, unfortunately, only on Linux, it fails to copy the content. I'm
still not sure the reason. This patch just avoids running the last part
only on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D5742
--HG--
extra : moz-landing-system : lando
Although this reftest is sometimes failure on Android, it is no meaning to run
this test on Android due to no spellchekcer on Firefox Android.
Differential Revision: https://phabricator.services.mozilla.com/D5745
--HG--
extra : moz-landing-system : lando
This enables the editor directory to be linted, and fixes the remaining issues raised by ESLint. Various rules were fixed here including, no-shadow, no-undef, no-unused-vars and others.
I've generally gone conservative, disabling rules where it doesn't make sense to fix them (e.g. sometimes suggests use-services for tests, but it is only used once, or within a Chrome script).
Depends on D5585
Differential Revision: https://phabricator.services.mozilla.com/D5587
--HG--
extra : moz-landing-system : lando
These are all automatically generated by ESLint with the --fix option.
Depends on D5584
Differential Revision: https://phabricator.services.mozilla.com/D5585
--HG--
extra : moz-landing-system : lando
Also block-disables no-multi-spaces for test_resizers_resizing_elements.html
Differential Revision: https://phabricator.services.mozilla.com/D5584
--HG--
extra : moz-landing-system : lando
HTMLEditor::RefereshGrabber() is an XPCOM method which is used by BlueGriffon.
Additionally, it's called internally. Therefore, we should create a non-virtual
method for this and all internal users should use it.
This patch renames all other related methods to *Internal() for consistency.
Additionally, this fixes a bug of nested calls of ShowGrabber() and
HideGrabber(). This makes CreateGrabber() sets mGrabber directly since
it may be cleared by HideGrabber() while it's running, and also makes
HideGrabber() moves all members who will be cleaned up with local variables
and always clean them up even if it meats an error.
Differential Revision: https://phabricator.services.mozilla.com/D5424
--HG--
extra : moz-landing-system : lando
Masayuki Nakano
Csoregi Natalia
Dorel Luca
Makoto Kato
Gurzau Raul
Ehsan Akhgari
Cosmin Sabou
Ciure Andrei
Tom Schuster
Edgar Chen
Gabriele Svelto
Cristina Coroiu
Julian Descottes
Dão Gottwald
arthur.iakab
Andrew McCreight
Noemi Erli
Emilio Cobos Álvarez
Andreea Pavel
Margareta Eliza Balazs
Mark Banner
Bogdan Tara