`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--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
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
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
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
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
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
nsITableEditor::GetNextCellElement() is an XPCOM method but it's used internally
a lot. So, HTMLEditor should implement it with non-virtual method and
internal users should use the non-virtual method.
Therefore, this patch creates HTMLEditor::GetNextSelectedTableCellElement().
Differential Revision: https://phabricator.services.mozilla.com/D4194
--HG--
extra : moz-landing-system : lando
HTMLEditor::GetFirstSelectedCell() is an XPCOM method, but used internally a
lot. Therefore, we should create a non-virtual method for internal use.
This patch creates HTMLEditor::GetFirstSelectedTableCellElement(), and it
won't return NS_SUCCESS_EDITOR_ELEMENT_NOT_FOUND since nobody needs the
value. It's enough to check whether the result is nullptr without error for
any callers.
Differential Revision: https://phabricator.services.mozilla.com/D4060
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetCellAt() is an XPCOM method, but this is called internally
a lot. So, we should create non-virtual method for internal use.
The XPCOM method retrieves a <table> element if given element is nullptr.
However, no internal user needs this feature. So, we can create
GetTableCellElementAt() simply. Then, we can get rid of nsresult and
ErrorResult from it.
Differential Revision: https://phabricator.services.mozilla.com/D3956
--HG--
extra : moz-landing-system : lando
HTMLEditor::GetTableSize() is an XPCOM method but used internally a lot.
Therefore, it shouldn't be called for internal use. Additionally, the
callers need to declare two int32_t variables, but this causes the code
messy. Therefore, this patch creates TableSize struct and it implements
HTMLEditor::GetTableSize(). Then, all callers of it is replaced with
TableSize struct.
New TableSize struct does not support computes <table> element from anchor
of Selection since there is no user of this in C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D3953
--HG--
extra : moz-landing-system : lando
HTMLEditor::GetCellIndexes() is an XPCOM method and used a lot internally.
So, we need alternative way to retrieve indexes of a cell without virtual
calls. In a lot of places, receiving indexes with 2 int32_t variables causes
the code messy and that causes making it harder to understand which are
index for same cell and where they come from. So, making both of them stored
one variable makes the callers simpler. Therefore, this patch creates
CellIndexes stack class to get and store the result simply. Then, this makes
all callers of GetCellIndexes() use this new class and makes GetCellIndexes()
also use this new class.
FYI: This patch does NOT put ErrorResult instances in small block scope as far as
possible. The reason is, I see its destructor in profile sometimes. I don't think
that we should use nsresult& instead of ErrorResult& only for this performance
reason, but I think that creating each instance in loops does not make sense.
Differential Revision: https://phabricator.services.mozilla.com/D3849
--HG--
extra : moz-landing-system : lando
Nobody uses nsITableEditor.getNextRow(). Therefore, this patch removes this
XPCOM API.
Differential Revision: https://phabricator.services.mozilla.com/D3949
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetNextRow() is an XPCOM method. Therefore, we should have
a non-virtual method for internal use of it.
This changes the definition in nsITableEditor. First, it allows only <tr>
element as what HTMLEditor::GetNextRow() has actually done. Then, changes
the return type to Element since it always returns an element node.
Differential Revision: https://phabricator.services.mozilla.com/D3948
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetFirstRow() is an XPCOM method, so, for internal use,
we should create non-virtual method, that is GetFirstTableRowElement().
This patch makes it never return NS_SUCCESS_EDITOR_ELEMENT_NOT_FOUND since
nobody refers it and it's detectable. If the method returns nullptr without
error, it's the case of NS_SUCCESS_EDITOR_ELEMENT_NOT_FOUND.
Additionally, this patch changes the return type of GetFirstRow() from
Node to Element since it always return an Element node if not null.
Differential Revision: https://phabricator.services.mozilla.com/D3780
--HG--
extra : moz-landing-system : lando
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.
nsITableEditor is now a builtin class. So, it's implemented only by HTMLEditor. Therefore, AutoSelectionSetterAfterTableEdit can use HTMLEditor.
Then, nsITableEditor.setSelectionAfterTableEdit() can be removed from nsITableEditor and moved to HTMLEditor as non-virtual method since nobody uses it from JS.
MozReview-Commit-ID: KnN6Fw4TYyn
--HG--
extra : rebase_source : 48412a5f81f30d9ada47550fdb4d1ee0d88de6f4
If we make nsIEditor a builtin class, that means that its instance can be only TextEditor or HTMLEditor. Then, users of nsIEditor can use concrete classes such as EditorBase, TextEditor or HTMLEditor instead. Then, the users can reduce unnecessary QI and a lot of virtual calls if we'll create non-virtual methods.
So, let's make editor related interfaces builtin classes.
MozReview-Commit-ID: 93WfsSDuJiJ
--HG--
extra : rebase_source : 39151eb4ffaaf195fec57234ea84c9f4066c58d1
Masayuki Nakano
Noemi Erli
Boris Zbarsky
Birunthan Mohanathas