`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
`PresShell.h` is exposed as `mozilla/PresShell.h` and `PresShell` is the only
concrete class of `nsIPresShell`. Therefore, we have no reason to access
`PresShell` via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D23277
As far as I've tested, Chrome does not throw exception even when editor is
destroyed or editor content is modified unexpectedly. So, we should return
`NS_OK` from most public methods of editor when internal methods return
`NS_ERROR_EDITOR_DESTROYED` or `NS_ERROR_EDITOR_UNEXPECTED_DOM_TREE`.
Differential Revision: https://phabricator.services.mozilla.com/D20811
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
Currently, calling nsITableEditor.insertTableCell() does not cause dispatching
"input" event since it does not create AutoPlaceholderBatch. Additionally,
different from InsertTableRowsWithTransaction() and
InsertTableColumnsWithTransaction(), it does not create
AutoTopLevelEditSubActionNotifier.
Because of those APIs should work similarly, we should make it creates
both auto class instances.
Differential Revision: https://phabricator.services.mozilla.com/D12248
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
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
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
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
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
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
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
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
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
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
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
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
This patch renames HTMLEditor::DeleteColumn() to
HTMLEditor::DeleteTableColumnWithTransaction() and cleans up its implementation.
Differential Revision: https://phabricator.services.mozilla.com/D5934
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
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
This patch renames HTMLEditor::DeleteRow() to
HTMLEditor::DeleteTableRowWithTransaction() and cleans up its implementation.
Differential Revision: https://phabricator.services.mozilla.com/D5931
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
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
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
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
Noemi Erli