GitLab's comment calls scrollTop on input event handler. The scollTop may cause
reflow. When causing reflow, editor is destroyed and initialized again. Then
nsTextEditorState will set current value to editor. But this is failure.
By bug 1465702, selection is cached in edit action. When initializing editor,
selection controller is updated, so selection into cache becomes invalid. It
means that all selection methods will return error since document is different.
So we should update selection cache when initializing editor.
Also, I cannot create test case for this situation since we have to cause reflow
in input and/or composition event. Do you have any idea?
Differential Revision: https://phabricator.services.mozilla.com/D16944
--HG--
extra : moz-landing-system : lando
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
A lot of listeners are now notified with RefPtr for concrete classes.
Therefore, we can reduce size of arrays to listeners without damage for
the performance.
Differential Revision: https://phabricator.services.mozilla.com/D12403
--HG--
extra : moz-landing-system : lando
Similar to EditorBase::mSavedSel, we can move EditorBase::mRangeUpdater too
because of it's referred only when there is AutoEditActionDataSetter instance
so that it also does not need to be in the cycle collection.
And now, it can be marked as MOZ_STACK_CLASS and remove cycle collection
support.
Differential Revision: https://phabricator.services.mozilla.com/D12402
--HG--
extra : moz-landing-system : lando
EditorBase::mSavedSel is used only by EditorBase methods which are called only
by AutoSelectionRestorer. Additionally, AutoSelectionRestorer requires
AutoEditActionDataSetter instance. So, we don't need to keep create for
editor instance anymore. And also we don't need to keep it in the cycle
collection.
Note that SelectionState class is also used by PlaceholderTransaction.
Therefore, we cannot make it MOZ_STACK_CLASS.
Differential Revision: https://phabricator.services.mozilla.com/D12401
--HG--
extra : moz-landing-system : lando
EditorBase::mDirection is set and clear only when
EditorBase::AutoEditActionDataSetter::SetTopLevelEditSubAction(). So, the
direction is related to the top level edit sub action, and we can move it
into AutoEditActionDataSetter.
Note that except EditSubAction::eDeleteSelectedContent, the relation between
sub-action and direction is fixed so that this patch checks the relation with
MOZ_ASSERT. If we could replace EditSubAction::eDeleteSelectedContent with
information of direction, we'd remove the new member of
AutoEditActionDataSetter, though.
Differential Revision: https://phabricator.services.mozilla.com/D12400
--HG--
extra : moz-landing-system : lando
EditorBase::mTopLevelEditSubAction is set only by
EditorBase::OnStartToHandleTopLevelEditSubAction() and
EditorBase::OnEndToHandleTopLevelEditSubAction() and they are called only by
AutoTopLevelEditSubActionNotifier().
So, this is used only in stack when a public method of editor is called.
Therefore, we can move it into EditorBase::AutoEditActionDataSetter. Then,
we can reduce heap allocation for editor instances.
Differential Revision: https://phabricator.services.mozilla.com/D12399
--HG--
extra : moz-landing-system : lando
Currently, a lot of code dispatch "input" event and some of them dispatch
"input" event with wrong interface and/or values. Therefore this patch
creates nsContentUtils::DispatchInputEvent() to make all of them dispatch
correct event.
Unfortunately, due to bug 1506439, we cannot set pointer to refcountable
classes of MOZ_CAN_RUN_SCRIPT method to nullptr. Therefore, this patch
creates temporary RefPtr<TextEditor> a lot even though it makes damage to
the performance if it's in a hot path.
This patch makes eEditorInput event dispatched with
InternalEditorInputEvent when "input" event should be dispatched with
dom::InputEvent. However, this patch uses WidgetEvent whose message is
eUnidentifiedEvent and setting WidgetEvent::mSpecifiedEventType to
nsGkAtoms::oninput when "input" event should be dispatched with
dom::Event because we need to keep that eEditorInput and
InternalEditorInputEvent are mapped each other.
Differential Revision: https://phabricator.services.mozilla.com/D12244
--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
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
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
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
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
EditorBase::AreNodesSameType() is overridden only by HTMLEditor and the
implementation is enough simple to re-implement in EditorBase.
Additionally, this is called from condition of a loop in
JoinNodesDeepWithTransaction(). So, the virtual call cost may make damage
to the performance.
Differential Revision: https://phabricator.services.mozilla.com/D3460
--HG--
extra : moz-landing-system : lando
Fortunately, despite of becoming public method,
HTMLEditor::CreateElementWithDefaults() can be used by internal methods too
since it does not touch undo transactions nor the DOM tree, and does not
refer mRules nor GetSelection(). So, we can make it public and make any
C++ callers use it.
This patch also creates non-virtual methods,
EditorBase::BeginTransactionInternal(), EditorBase::EndTransactionInternal(),
TransactionManager::BeginBatchInternal() and
TransactionManager::EndBatchInternal().
Although, this could be replaced with API to use PlaceholderTransaction,
we should investigate it when we have much time.
Differential Revision: https://phabricator.services.mozilla.com/D2989
--HG--
extra : moz-landing-system : lando
Although HTMLEditor::EndUpdateViewBatch() calls a method of nsIHTMLEditor,
the additional work after calling EditorBase::EndUpdateViewBatch() is enough
simple. So, we can move the implementation in HTMLEditor to EditorBase and
make it non-virtual.
Differential Revision: https://phabricator.services.mozilla.com/D2705
--HG--
extra : moz-landing-system : lando
HTMLEditor::IsModifiableNode() is enough simple and can be checked in
EditorBase. So, we should make it non-virtual and check if instance is
HTMLEditor in EditorBase::IsModifiableNode().
Differential Revision: https://phabricator.services.mozilla.com/D2706
--HG--
extra : moz-landing-system : lando
There is no non-virtual method to modify
EditorBase::mAllowsTransactionsToChangeSelection. Therefore,
AutoTransactionsConserveSelection calls virtual method,
nsIEditor::SetShouldTxnSetSelection() twice (from both constructor and
destructor). So, we should save this unnecessary cost.
MozReview-Commit-ID: B7TYGnGtuLB
--HG--
extra : rebase_source : 26ce77fb63a1967cca88b002cd65e1105477a63d
For explaining what it does clearer, we should rename it and corresponding
member.
MozReview-Commit-ID: 6U8FgfHBbCL
--HG--
extra : rebase_source : 50bc3ce0d3b9900939c7e6e8a137abe2288cf727
nsIEditor::ShouldTxnSetSelection() is used only by DeleteRangeTransaction
(even if including comm-central and BlueGriffon) and there is a non-virtual
method EditorBase::GetShouldTxnSetSelection(). So, we can remove this.
MozReview-Commit-ID: JWSCw9k6lI0
--HG--
extra : rebase_source : 2509274216a1493134757a7d106464f06ea0ba57
Some methods to get editor root etc has unnecessary refcounting and it isn't
const method. So we should remove unnecessary refcounting and change to
const method.
Differential Revision: https://phabricator.services.mozilla.com/D2499
--HG--
extra : moz-landing-system : lando
This patch creates non-virtual method, EditorBase::GetDocumentCharsetInternal(),
for internal use of nsIEditor::GetDocumentCharacterSet() since the virtual
call method is redundant and the caller cannot be marked as const.
MozReview-Commit-ID: v6kDo2eKg3
--HG--
extra : rebase_source : 07f6dd8341cb6686835db2ee3ded479323cccca9
TextEditor::GetAndInitDocEncoder() modifies only mCachedDocumentEncoder and
mCachedDocumentEncoderType which are cache of the method to save recreation
cost of document encoder when same type document encoder is requested.
So, with marking them mutable, we can change the method to a const method.
MozReview-Commit-ID: 80W0NtQhJOR
--HG--
extra : rebase_source : 84f4b49fe3a3124c0de99b39a2141a8cee553e54
When setting contenteditable to false, editing session destroys HTMLEditor.
Destroying HTMLEditor means that selection visibility is reset by
FinalizeSelection.
So after calling TearDownEditorOnWindow on nsHTMLDocument, we should initialize
selection visibility if current focus is text control that has editor.
MozReview-Commit-ID: 4V8kZtOtKO3
--HG--
extra : rebase_source : 9d90c12b3c93e4dfd95095ce29a26e5fdd83f952
When setting contenteditable to false, editing session destroys HTMLEditor.
Destroying HTMLEditor means that selection visibility is reset by
FinalizeSelection.
So after calling TearDownEditorOnWindow on nsHTMLDocument, we should initialize
selection visibility if current focus is text control that has editor.
MozReview-Commit-ID: 4V8kZtOtKO3
--HG--
extra : rebase_source : 773c06bb22cf2da24fd11be9be8d7b0376da3e36
Calling EditorBase::EnableUndoRedo() without argument means that editor supports
unlimited undo/redo stack. AutoDisableUndo class calls it without argument
when it needs to restore undo/redo feature.
However, <input type="text"> and <textarea> limits number of maximum
transactions up to 1,000, perhaps for footprint. So, AutoDisableUndo should
store the last number of maximum transactions before disabling undo/redo from
the constructor.
MozReview-Commit-ID: CoI6ZXyTd3X
--HG--
extra : rebase_source : e2b9af17e5857dcc0a6781e254e45fdb790c9a9e
These are effectively equivalent to appending a <link> element to the body, are
not unused, and bring in a fair amount of complexity because even though they're
owned by the document and stored in the document's mStyleSheets, they're not
owned by it per se, which causes confusion.
Unless I've missed something, both bluegriffon and common-central use the
*Override APIs, which this patch leaves untouched.
MozReview-Commit-ID: EOSMOHj3A95
For preparing to fix bug 1465702, we need to split public methods of editor
which are used by both outside and itself or friends.
SelectAll() is used by both outside and TextEditor. So, we need to create
SelectAllInternal() and make TextEditor use it instead.
MozReview-Commit-ID: JtIlrfBYBSD
--HG--
extra : rebase_source : 5c29a9c1bb99f457f66f320b873b2c7b0f93fcde
There are two similar methods, but they are created with copy & paste.
So, the common code should be merged into new method, SetTextDirection().
Additionally, EditorBase::SwitchTextDirection() is a scriptable method but
nobody uses this from JS. So, we can make it from nsIEditor and this
patch renames it to ToggleTextDirection() since current name is too
similar to SwitchTextDirectionTo().
MozReview-Commit-ID: BX3M1OKxiD5
--HG--
extra : rebase_source : 74a5ff65adc96ba69792f2e63daf14828c505270
This moves NotifyEditorObservers() and GetInputEventTargetContent() into
protected member which should not be used by friends.
And also this moves IsModifiableNode() into protected member which can be
used by friends.
MozReview-Commit-ID: AxDBgTVED3V
--HG--
extra : rebase_source : 979c6cb0d075b3fd0106bd1c381aa3ef3b98ba78
InsertFromDrop is implemented on TextEditor only, so it can do devirtualize
this method. Also, this method is only called by drop event handler of
EditorEventListener, so it should rename to better name (OnDrop).
Differential Revision: https://phabricator.services.mozilla.com/D1592
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
EditorBase (and other editor classes) have 2 type of public methods. One is
true-public methods. I.e., they should be able to be called by anybody.
E.g., command handlers, event listeners, or JS via nsIEditor interface.
The other is semi-public methods. They are not called by the above examples
but called by other classes which are helper classes to handle edit actions.
E.g., TextEditRules, HTMLEditRules, HTMLEditUtils, CSSEditUtils and Transaction
classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make EditorBase have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in EditorBase.h
(except removes GetName() since there is no body of this method and removes
IterDirection since it's unused).
MozReview-Commit-ID: HBseKLL6pxx
--HG--
extra : rebase_source : 2251ff659d831d01a6778d38f4e2714fcf2d6ef4
CanPasteTransferable and PreDestroy aren't used from script (inc. comm-central
and bluegriffon), so we should move these to out of nsIEditor.
MozReview-Commit-ID: GRfBobAm2qi
--HG--
extra : rebase_source : 812792ff43da24bfd9cb99c4b3127e6acdc43ba1
This patch creates a stack class in TextEditRules, its name is
AutoSafeEditorData and make all public methods (except editor observer methods)
which may change DOM tree, fire some DOM events or calling some XPCOM listeners
create its instance in the stack. Then, it grabs associated editor instance
and its selection instance.
Next patch will make remaining public methods create AutoSafeEditorData.
MozReview-Commit-ID: 8oshdhL3ONQ
--HG--
extra : rebase_source : 591db71e45fe28ca93cbebd9bb7da8c16eae4466
It is unnecessary to keep virtual method for
mozInlineSpellChecker::SpellCheckAfterEditorChange, so we should remove virtual
keyword.
MozReview-Commit-ID: 2ry5uhMTFVC
--HG--
extra : rebase_source : ba86bb7c4e47598f83e3869733a238a740cef6b2
The patch is a bit large because all these methods except
SswitchTableCellHeaderType call each other; doing it piecemeal would have
required introducing, then removing, a bunch of QIs.
