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
