Gecko has some built-in UIs:
* to edit size of objects like <img>, <table> and absolute positioned elements.
* to edit position of absolute positioned elements.
* to add/remove table columns and rows.
Currently, those UIs are available in both designMode editor and contenteditable
editor only on Gecko. I.e., the other browsers' users cannot modify as such
without web apps implement such function. So, for compatibility with the
other browsers, we should hide those UIs by default. On the other hand, if
this is too risky for backward compatibility, we should not do that.
So, before doing that, we should collect actual usage data of object resizers,
inline table editing UI, positioning UI of absolute positioned elements with
telemetry probes.
This patch adds 3 sets of probes for each UI. One is percentage of showing
each UI in all instantiated HTMLEditor. The other is number of user interaction
of each UI in HTMLEditors which has shown the UI.
This patch makes all new probes as "opt-out" because they are really important
data since used for deciding whether those UIs are necessary or unnecessary.
MozReview-Commit-ID: B9Y6GTiCPw6
--HG--
extra : rebase_source : 00e49f31712e24cb269ad3aa65c7d13b7cccb3a5
Use fatal MOZ_ASSERT or non-fatal NS_ASSERTION instead.
MozReview-Commit-ID: 1QAsgoWpXDn
--HG--
extra : source : 9ca972b6b3e7d3b576e20a0bf412df51d82aad9f
extra : intermediate-source : a909a9d7bc9a53095e963a4bea45f4fc4aa85b72
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
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
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.
The work to migrate to Sqlite.jsm seems to have caused a timing problem
in our tests where shutdown the content process while this IPC message
is still unresolved. This causes us to destroy RemoteSpellCheckingEngineChild
without it having processed its RecvNotiy..., leading to the promise being
leaked. As far as I can tell this resolves all of our leak issues on try.
MozReview-Commit-ID: GdwVIp5dj1m
--HG--
extra : rebase_source : b7bf5838c53e40b49bea17df123028a2dbd26e5e
Currently, EditorBase handles most composition events. However, only
eCompositionChange event handler is in TextEditor and it's the main event
of handling composition. Therefore, we should make all composition event
handlers in one place for easier to read, and make them non-virtual.
MozReview-Commit-ID: BYDhiPyGKvo
--HG--
extra : rebase_source : ed9db0f49d7ae268c85359e48015e86584f9c999
This is simple mistake of bug 1451672.
EditorBase::CloneAttributesWithTransaction() sets both sourceElement and
destElement to aDestElement, but of course, it should set sourceElement to
aSourceElement.
Additionally, this patch adds mozilla specific web-platform tests to check
attribute cloning with basic edit operation.
MozReview-Commit-ID: GM1VjRHG7C3
--HG--
extra : rebase_source : 95427853442454525232df519ce5b5ad7bb12693
No one uses outputToStream even if c-c and BlueGriffon. We should remove this.
MozReview-Commit-ID: LEUtfc89DBe
--HG--
extra : rebase_source : f0c5aa918f577ca8a285afd2414fe3da6545fefc
No one uses postCreate from script even if c-c and BlueGriffon. So we should
devirtualize this
MozReview-Commit-ID: D3FKVEvG7Go
--HG--
extra : rebase_source : 9915a93ea8ae18bee251507a4c94fe66c0f03d0f
No one uses syncRealTimeSpell from script even if c-c and BlueGriffon. So
we should devirtualize this
MozReview-Commit-ID: AoOb165dOFa
--HG--
extra : rebase_source : e1a9dcdfa6cfe6c918a06a2738c38a6cb9441a1d
HTMLEditor::InsertElementAtSelection() doesn't check if selection is in
native anonymous subtree. Therefore, it could insert element into <input>
element etc.
This patch adds new API to EditorDOMPointBase to compute ancestor point which
is not in native-anonymous subtree and make
HTMLEditor::GetBetterInsertionPointFor() use it to not return point in any
native-anonymous subtrees.
Like this adds new comments into the method, we should optimize the method
since it may create a lot of transactions and dispatch a lot of mutation
events.
MozReview-Commit-ID: FknJfu6QCjS
--HG--
extra : rebase_source : 39dc110b1101134f7c704e64dbff89171fe50e47
According to existing comments, TextEditor::TypedText() and
HTMLEditor::TypedText() are intentional bottleneck to debug. However, only
for that purpose, it and its internal methods are made virtual. This really
doesn't make sense.
So, this patch creates TextEditor::OnInputText() for callers of TypedText()
with non-empty string, TextEditor::OnInputParagraphSeparator() for callers
of TypedText() with eTypeBreak (Enter key or insertParagraphSeparator),
HTMLEditor::OnInputLineBreak() for callers of TypedText() with eTypeBR
(Shift + Enter or insertLineBreak). Additionally, this creates internal
non-virtual methods for XPCOM methods which are used as internal methods of
TypedText(). One is InsertTextAsAction() for nsIPlatintextEditor.insertText().
the other is InsertParagraphSeparator() for nsIPlaintextEditor.insertLineBreak().
Although those new methods are not have "WithTransaction" postfix, they must
be clearer they'll use transactions since user input and actions should be
undo-able.
MozReview-Commit-ID: AmOkMqovIKA
--HG--
extra : rebase_source : 9c0f4b25fa2a36ad2f3394f72eb290824c31d82a
TextEditor::CreateBR() is just a wrapper of TextEditor::CreateBRImpl() for
automatically retrieving Selection of the editor.
And TextEditor::CreateBRImpl() should be renamed to
TextEditor::InsertBrElementWithTransaction() for making it clearer what
it does.
MozReview-Commit-ID: D8sjVdLrVrd
--HG--
extra : rebase_source : f269f5c3ce598d221d7263c111475dab0dd5f19f
Similar to EditorBase::ReplaceContainerWithTransaction(),
EditorBase::InsertContainerAbove() may set an attribute to newly created element
if it's specified. However, for avoiding the null check, let's make them
as references rather than pointers and treat nsGkAtoms::_empty as nullptr for
making the code safer.
This patch removes "Above" from the method name since it's redundant.
"Insert" sounds like inserting a node, and "Container" means to keep existing
children with new element in EditorBase.
MozReview-Commit-ID: 6EnkKHynYSP
--HG--
extra : rebase_source : d4b4c1a611c46a0f4d86389aab3331af565199d2
This patch renames EditorBase::MoveNode() to
EditorBase::MoveNodeWithTransaction() and redesign its parameters including
replacing a set of container node and offset in it to EditorDOMPointBase.
However, it takes magic number -1 as meaning end of the container.
Therefore, this patch adds MoveNodeToEndWithTransaction() for keeping the
callers simple.
MozReview-Commit-ID: BeTq5c7GQNN
--HG--
extra : rebase_source : b3a617a5a1a493cb0fcbefe2d9a9708b0257b1a8
The parameters of EditorBase::ReplaceContainer() are complicated. For example,
if it's specified as cloning all attributes, aAttribute and aValue are ignored
because CloneAttributes() removes all existing attributes but ReplaceContainer()
sets attributes before calling CloneAttributes(). This method has 3 modes:
1. Just replaces aOldContainer with new element.
2. #1 and clones all attributes from aOldContainer to the new element.
3. #1 and sets aAttribute of the new element to aValue.
Therefore, this patch creates 3 inline wrappers of the renamed method.
MozReview-Commit-ID: IsPu2uZuU8f
--HG--
extra : rebase_source : 02a23f48a91e0c9558126552a4c8d4b12c8b76bc
First, EditorBase::DeleteSelection() is never used since
TextEditor::DeleteSelection() overrides it but does not call it. So, this patch
makes EditorBase::DeleteSelection() only returns NS_ERROR_NOT_IMPLEMENTED.
Next, EditorBase::DeleteSelectionImpl() actually removes content for
TextEditor::DeleteSelection(). So, it should be named as
DeleteSelectionWithTransaction(). However, it'll be done in the following
patch. On the other hand, its callers are EditorBase::HandleKeyPressEvent()
and EditorBase::DeleteSelectionAndPrepareToCreateNode(). Fortunately, they
can be moved to TextEditor simply. Therefore this patch moves the methods
to TextEditor for making related methods in a place.
Then, we can make the implementation of nsIEditor::TextEditor() as a non-virtual
method, TextEditor::DeleteSelectionAsAction().
MozReview-Commit-ID: KXFDhW3G9lA
--HG--
extra : rebase_source : 15986979279b2cae3b61cda1bf6bf3d9e4987f3f
EditorBase::SplitNodeImpl() is called by SplitNodeTransaction::DoTransaction()
for actually splitting a node. However, "WithoutTransaction" postfix is really
redundant. Perhaps, just naming DoSplitNode() is better since "Impl" isn't
unclear and not useful if somebody wants to use it as a utility method and
there has already been EditorBase::SplitNode() which is an override of
nsIEditor::SplitNode(). It must not be good to use same name for different
purpose (EditorBase::SplitNode() creates a transaction).
MozReview-Commit-ID: Akjeyp52vVv
--HG--
extra : rebase_source : dcb29cec2749431b59068b670b68e5cd61b18588
This patch renames:
EditorBase::SplitNode() -> EditorBase::SplitNodeWithTransaction()
EditorBase::SplitNodeDeep() -> EditorBase::SplitNodeDeepWithTransaction()
HTMLEditRules::MaybeSplitAncestorsForInsert() ->
HTMLEditRules::MaybeSplitAncestorsForInsertWithTransaction()
Note it might be that some callers of those methods should be renamed too.
However, we should do it in follow up bug after landing those patches since
we can investigate it with searchfox.org after landing patches.
MozReview-Commit-ID: FfxCfaI85z5
--HG--
extra : rebase_source : 143960de45791c72dbf4d436f65e55452b4f7b10
EditorBase::CreateNode() creates an element node with transaction. I.e., it's
undoable. So, if somebody would use this method as a helper method for changing
the DOM tree, that would cause unexpected undoable transaction. So, we should
make the method name clearer to avoid such bug.
MozReview-Commit-ID: GZsOGBfqog
--HG--
extra : rebase_source : 8b7539a680ee88f3557acb0837fe1a021d842323
So, this patch replaces the setter with non-virtual method and removing the
getter since where is already non-virtual getter method.
MozReview-Commit-ID: Is19Yriz8t8
--HG--
extra : rebase_source : bb2f49f380ddb2e2f96e8690effd8d47d24ae0ae
This crash is that HTMLEditor::ClearStyle returns nullptr for aNode even if
successful.
When current start node and offset isn't within ancestor limiter,
HTMLEditor::ClearStyle will return nullptr for split node even if successful.
Because SplitNodeTransation returns error since Selection::Collapse is failed.
Then, SplitNodeDeep in HTMLEditor::SplitStyleAvovePoint returns error. But
this error is ignored. So node will becomes null even if successful.
CreateStyleForInsertText will set new selection when there is split node, so
we shouldn't set selection on ClearStyle.
Also, InsertNodeTransation is ignored for error when Collapse is failed, but
SplitNodeTransaction isn't ignored. We should create a rule when collapse is
failed on transaction.
And at feature, we shouldn't set selection in CreateStyleForInsertText, and
then, it should return new insertion point for InsertText instead of setting
new selection.
MozReview-Commit-ID: BRKWLqTfrvC
--HG--
extra : rebase_source : 2cd025e9d40688f643a843b39512dccc2bb7c4a2
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
It is unnecessary to get PresShell for nsStyleText, so we can return bool
instead of nsresult and can change it to static method.
MozReview-Commit-ID: LGrdcaJuLO
--HG--
extra : rebase_source : bb6b6d990741c7b478e9699ae84cc6b89a765bf7
Bug 768765 isn't enough for fix. Since Selection::GetAnchorFocusRange can
return nullptr, we should consider this condition.
And I cannot reproduce this using crash test, so I add mochitest for this.
MozReview-Commit-ID: 8Ei5YBIBuWv
--HG--
extra : rebase_source : cd11517f73179d949479716a83baec0e1f492eca
This is regression of bug 1423835.
When I fixed the bug, I accidentally changed the result of
HTMLEditRules::JoinNodesSmart() to use new API. However, it was simple
misunderstand. The original code sets the initial value of result to
{ aRightNode - aLeftNode.Length() } but I understood it as
{ aRightNode - aRightNode.Length() }. Therefore, this patch backs out the
patch only for this line.
MozReview-Commit-ID: 5rD7YFij8v
--HG--
extra : rebase_source : c11770892ab7416b9bf5d3329fc8b7b413387747
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
We should not use nsIDOMDocument if unnecessary. Because it needs QI to access
nsIDocument.
MozReview-Commit-ID: CMF3tmvBTB9
--HG--
extra : rebase_source : e832023be8d59a2c1e01bd423e6f058b0708dfe9
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
For nsCSSAnonBoxes.cpp, nsCSSPseudoElements.cpp, nsDirectoryService.cpp, the
corresponding .h file includes nsStaticAtom.h. For the other files in this
patch, nsStaticAtom.h is not needed at all.
MozReview-Commit-ID: IpMmbXwZHhu
--HG--
extra : rebase_source : 46d0a6b40a41ee233adad7c205cf907fa27de34a
This is a simple bug of internal API of HTMLEditor. HTMLEditor::GetBlock()
tries to retrieve nearest ancestor block node (including itself) of a node.
HTMLEditor::GetBlock() may have ancestor limiter typically it's active
editing host to prevent to modify editing host or its ancestor accidentally.
However, it forgets to call HTMLEditor::GetBlockNodeParent() with the given
ancestor limit node. Therefore, if editing host is an inline element and
its parent is a block element, the editing host is split accidentally.
MozReview-Commit-ID: Ermmxdnk4KB
--HG--
extra : rebase_source : c9b57c5bb28cd63b6f16702317f7ddb7fb5a26f6
To reduce QI, I would like to replace nsIDOMNode with nsINode. And some
parameters in *DataTransder.cpp's methods is unused (it uses as nullptr),
so we should remove these parameters.
Also nsIDOMNodeList is unused now, so we should remove this including.
MozReview-Commit-ID: 1QTIkxDazjJ
--HG--
extra : rebase_source : 3961e897fcaa96975facc822821f1e223cab358d
nsIClipboardDragDropHooks and nsIClipboardDragDropHookList allow XUL apps
to customize drag and drop operation and paste operation. However, this
feature was used only by ChatZilla and it doesn't work on Gecko anymore.
So, we can get rid of them from our tree.
MozReview-Commit-ID: Ibs3V1gI8Ry
--HG--
extra : rebase_source : 83428293d59aaca432d76c71b214aa7799f7f9de
nsIEditor.numberOfUndoItems and nsIEditor.numberOfRedoItems are shortcut
property for nsITransactionManager.numberOfUndoItems and
nsITransactionManager.numberOfRedoItems of the editor. However, anybody
uses nsITransactionManager directly. So, we can get rid of them.
MozReview-Commit-ID: 70J0bsxDNCC
--HG--
extra : rebase_source : fd0847687fe595b257b0256a5f1faa5f2df5f972
nsITransactionListener::AddListener() and
nsITransactionListener::RemoveListener() are of course virtual methods.
Additionally, they are safe to call without grabbing the TransactionManager's
instance with local variable. Therefore, if EditorBase has methods to
add/remove transaction listener to/from its transaction manager, we don't
need EditorBase::GetTransactionManager() anymore.
So, this patch adds AddTransactionListener() and RemoveTransactionListener() to
EditorBase and TransactionManager, and remove
EditorBase::GetTransactionManager() (not nsIEditor's one).
MozReview-Commit-ID: FkPa1YgfagD
--HG--
extra : rebase_source : 8ef7796136804e3d7604c5ca5417fb3379606b93
nsIEditor::EnableUndo() and nsITransactionManager::Clear(),
nsITransactionManager::SetMaxTransactionCount() are called a lot but they are
virtual and some of or all of them are called once. There should be each
non-virtual method to do what each root caller wants. Therefore, this patch
adds EditorBase::EnableUndoRedo(), EditorBase::DisableUndoRedo(),
EditorBase::ClearUndoRedo(), TransactionManager::EnableUndoRedo(),
TransactionManager::DisableUndoRedo() and TransactionManager::ClearUndoRedo().
Note that this patch makes TransactionManager won't clear mUndoStack nor
mRedoStack if mDoStack is not empty. This is checked only by
TransactionManager::SetMaxTransactionCount() but according to the comment,
TransactionManager::Clear(), TransactionManager::UndoStack() and
TransactionManager::RedoStack() should check it too.
MozReview-Commit-ID: 6qBZOQNwdhw
--HG--
extra : rebase_source : 3249137f7acca0b4698713ab732774140bcc27e8
EditorBase::Undo() and EditorBase::Redo() implement only undo/redo function.
TextEditor::Undo() and TextEditor::Redo() call them with calling some
notification methods. However, this causes redundant AutoRules instance
creation and doesn't make sense to separate them under current design.
Therefore this patch merges them into TextEditor. Unfortunately, they are
XPCOM methods but we cannot implement proper overloads of non-virtual since
they are already minimized design. Fortunately, reducing only one virtual
call per undo/redo isn't so effective. So, let's keep simpler design.
Additionally, this patch makes them stop committing composition because
Chrome does not commit composition even if "undo"/"redo" is requested with
execCommand() during composition and it doesn't make sense to try to
undo/redo after committing composition since first undoable transaction
becomes the committing composition and committing composition causes
removing all transactions from redo transaction queue.
MozReview-Commit-ID: 78qlV2I9Lzk
--HG--
extra : rebase_source : 545c787d47fe02bf7e085be9d3ae028816750e69
Now, both TransactionManager.h and TransactionStack.h are exposed. So,
TransactionManager::GetNumberOfUndoItems() and
TransactionManager::GetNumberOfRedoItems() can be rewritten with non-virtual
inline methods because they just return mUndoStack.GetSize() and
mRedoStack.GetSize(). Then, we can implement EditorBase::NumbeOfUndoItems(),
EditorBase::NumberOfRedoItems(), EditorBase::CanUndo() and
EditorBase::CanRedo() as inline methods.
MozReview-Commit-ID: 3CJd0VrlvFY
--HG--
extra : rebase_source : 6848d80a395f1c161e10bfb50d15bd63de288095
Then, all classes in editor/txmgr is now in mozilla namespace and all
headers which are included by other directory are now exposed. So,
we can remote local includes from other directories now.
MozReview-Commit-ID: Kdb1c4Hp9Sy
--HG--
rename : editor/txmgr/nsTransactionStack.cpp => editor/txmgr/TransactionStack.cpp
rename : editor/txmgr/nsTransactionStack.h => editor/txmgr/TransactionStack.h
extra : rebase_source : 75035e9e618680af9188820595ab050b612a456f
A lot of methods take |const EditorRawDOMPoint&| as their argument. However,
some of them are called with EditorDOMPoint::AsRaw(). This is not good for
performance because:
1. Needs to create temporary instance of EditorRawDOMPoint.
2. EditorRawDOMPoint::AsRaw() may be used by simple mistake.
3. Such methods may call EditorRawDOMPoint::Offset(), however, it's not copied
to the original EditorDOMPoint instance. So, callers may need to compute
offset again.
So, such methods should be changed to template methods if they are not virtual
method and AsRaw() should be gotten rid of for prevent it looking not expensive.
MozReview-Commit-ID: DAqqW4a2EMS
--HG--
extra : rebase_source : 120b920477fe6e7231271411a00994325acdb842
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
When calling UninitSpellChecker during calling UpdateDictionary, this crash
occurs. Since Thunderbird calls UninitSpellChecker by [Recheck Text] button,
this only occurs on Thunderbird.
After calling UninitSpellChecker, we should not update dictionary.
MozReview-Commit-ID: K4SPJ5FDo8n
--HG--
extra : rebase_source : d760c6472f56cef520c399e8c1f20536c3a22e36
When calling UninitSpellChecker during calling UpdateDictionary, this crash
occurs. Since Thunderbird calls UninitSpellChecker by [Recheck Text] button,
this only occurs on Thunderbird.
After calling UninitSpellChecker, we should not update dictionary.
MozReview-Commit-ID: K4SPJ5FDo8n
--HG--
extra : rebase_source : 67fa439e2a4767502ca84095754150d513a939b2
extra : amend_source : 1b065ebe275cefc02809478eb7d6d807f19dbbee
The DOMMatrix.cpp changes are because it was sneaking in headers via another
unified file.
MozReview-Commit-ID: GPp9WOywI5D
--HG--
rename : dom/base/nsGenericDOMDataNode.cpp => dom/base/CharacterData.cpp
rename : dom/base/nsGenericDOMDataNode.h => dom/base/CharacterData.h
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
Except table access and XPCOM methods for c-c, tests and etc, we can remove
more nsIDOMElement usages to avoid QI.
MozReview-Commit-ID: HO5kAaZAs6Q
--HG--
extra : rebase_source : 41ede0bace33504ad852dc4e0016ea346cd7bdee
Before bug 1413181, HTMLEditRules::SplitMailCites() receives left node of
split node with |leftCite| from SplitNodeDeep(). However, the out argument
was removed by the bug and now, it can be retrieved with
SplitNodeResult::GetPreviousNode(). Its result is used for creating <br>
element etc, but not set to |leftCite| but HTMLEditRules::SplitMailCites()
still checks if |leftCite| is empty to remove it from the DOM tree.
So, now, both |leftCite| and |rightCite| are not necessary and
HTMLEditRules::SplitMailCites() should use |previousNodeOfSplitPoint|
instead of |leftCite|.
MozReview-Commit-ID: 408MJt6X1IV
--HG--
extra : rebase_source : fa6095ccc972d33afe8deb0f124adffea7371f4e
EditorBase::GetStartNodeAndOffset() and EditorBase::GetEndNodeAndOffset() are
just wrappers of EditorBase::GetStartPoint() and EditorBase::GetEndPoint().
They may *compute* offset in the container node even if some callers don't
need the offset. Therefore, we should get rid of them and make all callers
use EditorBase::GetStartPoint() or EditorBase::GetEndPoint() directly.
Note that EditorBase::GetStartNodeAndOffset() and
EditorBase::GetEndNodeAndOffset() returns NS_ERROR_FAILURE if
EditorBase::GetStartPoint() or EditorBase::GetEndPoint() returns not set point.
Therefore, checking the result is set equals checking the old nsresult as
an error.
MozReview-Commit-ID: JLwqRMFLjHC
--HG--
extra : rebase_source : 0eb6bf4ba80e8139c6b9f36723d77d23f2b9099e
There are 2 callers of TextEditRules::CheckBidiLevelForDeletion(). One of them
will start to use EditorRawDOMPoint. Therefore, making it take
|const EditorRawDOMPoint&| instead of |nsINode*| and offset in it keeps the
caller simpler.
MozReview-Commit-ID: DRJXo8gnzba
--HG--
extra : rebase_source : a64d1033699245f54a8f8e6a9b93457e12f33e6c
Similar to the constructor of WSRunObject, PriorVisibleNode() and
NextVisibleNode() callers may become ugly if the callers start to use
Editor(Raw)DOMPoint. So, let's make them take Editor(Raw)DOMPoint instead of
a pair of nsINode* and offset in it.
Note that a lot of callers of them already use Editor(Raw)DOMPoint. So, we
don't need to keep maintain overloads which takes nsINode* and offset in it
directly.
MozReview-Commit-ID: 3avMtL000nd
--HG--
extra : rebase_source : f8c83e2fabeb5a94a1729c626583a6699636b06c
The following patches make some WSRunObject users use EditorRawDOMPoint or
EditorDOMPoint instead of a pair of nsINode and offset in it. Then, the
code becomes too long like:
> WSRunObject object(mHTMLEditor, pointToDoSomething.GetContainer(),
> pointToDoSomething.Offset());
This is ugly and not easier to read than:
> WSRunObject object(mHTMLEditor, pointToDoSomething);
So, we should create alternative constructor of WSRunObject first.
MozReview-Commit-ID: GiNWRBLl7zB
--HG--
extra : rebase_source : 8616956b9745db130283a4bdbd82155b1cfb2803
Editor(Raw)DOMPoint::IsEndOfContainer() checks mIsChildInitialized before
referring mChild. However, it may be true even if mParent is not a container
node like a text node. Therefore, if mParent is a text node and
mIsChildInitialized is true, it always returns true (i.e., even if mOffset
isn't same as length of mParent).
This patch makes it check mParent->IsContainerNode() before checking
mIsChildInitialized because after checking mIsChildInitialized, it validates
the relation of the members. So, this keeps the validation simple.
MozReview-Commit-ID: K2XrAZoNv2I
--HG--
extra : rebase_source : cba8190f199ab2e9d99547948ab50f0cc8c8ff88
We only use it for properties that return pixels anyway, so we can use it
without much problem.
This also fixes bug 1428974.
MozReview-Commit-ID: 5BbVOUdQT7o
It is unnecessary to use already_AddRefed for GetDocument and GetPresShell.
Then, if we remove already_AddRefed, we can replace this with const method.
MozReview-Commit-ID: KTVS0rYrY2i
--HG--
extra : rebase_source : 0199026410fc674f112c960b599a09bc7906cf85
Currently, HTMLEditor doesn't initialize caret position when it gets focus by
itself in most cases. Only when it's in designMode, it may move caret to the
first visible (not checking CSS actually).
In most cases, caret position is adjusted when EditorBase::InitializeSelection()
calls Selection::SetAncestorLimiter(). If selected range is outside of
new limiter, it moves caret to start of the new limiter. However, this is
really different behavior from the other browsers. The other browsers try
to move caret to the first editable text node or before the first editable
content such as <img>, <input>, etc.
This difference causes a serious incompatible issue with Draft.js. It doesn't
initialize caret position when it gets focus but it assumes that caret is
always set to before <br> element if there is no other content.
So, let's try to behave as what other browsers do as far as possible.
This patch makes editor behave as:
* if selection is already in the editing host except start of the editing host,
does nothing.
* if there is non-editable element before any editable node, move caret to
start of the editing host.
* if there is editable text node or element node which cannot have a text node,
move its start or before it.
* if there is no editable nodes which can contain text nodes, move caret to
start of the editing host.
Note that before applying this patch, in designMode, BeginningOfDocument() used
document element instead of <body> element. Therefore, it may set odd position
if <head> element has some text nodes with <script> or <style>. However,
this doesn't make sense and for making more consistent behavior between
designMode and contenteditable, this patch makes it use editing host (it's
<body> element if it's in designMode).
MozReview-Commit-ID: 5neYoTMq6Cc
--HG--
extra : rebase_source : c4d06b6864a221d7cd2833a007d73f7d67821e95
Per bug 1439813, some files in composer is for spellchecker, so we should move
it to /editor/spellchecker.
MozReview-Commit-ID: 6vlhC1TcZp5
--HG--
rename : editor/composer/EditorSpellCheck.cpp => editor/spellchecker/EditorSpellCheck.cpp
rename : editor/composer/EditorSpellCheck.h => editor/spellchecker/EditorSpellCheck.h
rename : editor/composer/nsComposeTxtSrvFilter.cpp => editor/spellchecker/nsComposeTxtSrvFilter.cpp
rename : editor/composer/nsComposeTxtSrvFilter.h => editor/spellchecker/nsComposeTxtSrvFilter.h
extra : rebase_source : b9c3fcf7e557a2ff4b58e81020fa7a9ec938d3af
txtsvc is ambiguous name, so we should use functional name instead.
XPIDL_MODULE still keeps 'txtsvc' because 'spellchecker' is already used by
extensions/spellchek/idl. And all IDLs for editor may move to /editor since
most IDLs for editor is on /editor.
MozReview-Commit-ID: v9a5ENEs2M
--HG--
rename : editor/txtsvc/TextServicesDocument.cpp => editor/spellchecker/TextServicesDocument.cpp
rename : editor/txtsvc/TextServicesDocument.h => editor/spellchecker/TextServicesDocument.h
rename : editor/txtsvc/moz.build => editor/spellchecker/moz.build
rename : editor/txtsvc/nsFilteredContentIterator.cpp => editor/spellchecker/nsFilteredContentIterator.cpp
rename : editor/txtsvc/nsFilteredContentIterator.h => editor/spellchecker/nsFilteredContentIterator.h
rename : editor/txtsvc/nsIInlineSpellChecker.idl => editor/spellchecker/nsIInlineSpellChecker.idl
rename : editor/txtsvc/nsISpellChecker.h => editor/spellchecker/nsISpellChecker.h
rename : editor/txtsvc/nsITextServicesFilter.idl => editor/spellchecker/nsITextServicesFilter.idl
extra : rebase_source : 38ea55fe974614b7bb829b614f7de1ee649dbbb1
To get a rid of some methods, I would like to replace nsIDOMNode usages with nsINode.
MozReview-Commit-ID: B0FVczayND0
--HG--
extra : rebase_source : ede058089332202ba0c05ddb61e0f119cbf52fcb
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
maxTextLength is unused from script, so I would like to move to TextEditor.
Also, there is no reason to keep setText on nsIPlainText.
MozReview-Commit-ID: CZ8pa9Pm8qt
--HG--
extra : rebase_source : ea58a20510b2211dcf440955ec8dc49d57337437
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
HTMLEditRules::WillInsertBreak() started to use HTMLEditRules::MakeBasicBlock()
to wrap existing inline elements with default paragraph separator if inline
elements are children of editing host. However,
HTMLEditRules::ApplyBlockStyle() called by HTMLEditRules::MakeBasicBlock() sets
mNewNode to last new block node. So, if it wraps inline elements after caret
position, mNewNode becomes after expected caret position and
HTMLEditRules::AfterEditInner() will move caret into it.
This patch make HTMLEditRules::WillInsertBreak() reset mNewNode with
caret position after calling HTMLEditRules::MakeBasicBlock().
Additionally, this patch fixes a bug of HTMLEditor::IsVisibleBRElement().
That is, it uses only editable nodes to check if given <br> element is
visible. However, editable state is not related to this check. If <br>
element is followed by non-editable inline node (except invisible data
nodes), it always visible. This bug caused getting wrong nodes with
HTMLEditRules::GetNodesFromSelection() which is used by
HTMLEditRules::MakeBasicBlock(). Therefore, this patch also adds lots of
EditorBase::Get(Next|Previous)ElementOrText*() and
HTMLEditor::Get(Next|Previous)HTMLElementOrText*() to ignore only invisible
data nodes.
Note that even with this fix, the range of nodes computed by
HTMLEditRules::GetNodesFromSelection() is still odd if only non-editable
elements follow a <br> node which is first <br> element after the caret
position. However, what is expected by the execCommand spec is unclear.
So, automated test added by this patch checks current inconsistent behavior
for now.
MozReview-Commit-ID: 2m52StwoEEH
--HG--
extra : rebase_source : 6b9b2338e35c4d2e89a405fd8e1ffc7b0873ca1e
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
EditorBase::JoinNodeDeep() returns a DOM point which was start of right node.
Currently, this is set before actually joining the nodes. Therefore, we see
warnings since right node which becomes joined node may have less children
than left node.
This patch also makes the NS_WARNING_ASSERTION to NS_ASSERTION since no tests
hit this. So, we can use it to detect regressions.
MozReview-Commit-ID: 3RmRP588AkF
--HG--
extra : rebase_source : 2cab458ffac566c81eb8d3f47e755ffacb1553d2
* The number is no longer selected on number input focus
MozReview-Commit-ID: AmR5c6YKTCP
--HG--
extra : rebase_source : fdaab23fca57f361c9185191d9c30e047375cbe8
* The number is no longer selected on number input focus
MozReview-Commit-ID: EoXNqhXwK95
--HG--
extra : rebase_source : b5a522e11796ec42c87019f6c3955e6c40eb21d0
This patch only fixes warning, not changing actual behavior of editor.
HTMLEditRules::ReturnInParagraph() splits paragraph *around* given point.
Therefore, from point of view of caller, offset of setting point may be
invalid after HTMLEditRules::ReturnInParagraph() handled the edit action.
In this case, invalidating stored child of the point may cause warning
since offset may be larger than length of its container.
So, if HTMLEditRules::ReturnInParagraph() handles the edit action,
the caller, HTMLEditRules::WillInsertBreak(), should cancel invalidating
the stored child for avoiding unnecessary warning.
MozReview-Commit-ID: DKJlr0Awwlo
--HG--
extra : rebase_source : 8fbefff3b46e55daf8db6342f00de904315d7fcc
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : 6cab2e6e7b4ba8cfb56d8320be24ca4afcbe55fb
extra : amend_source : 1d8c59086a9158a49dd270b64ecf8341ed4002ce
Before bug 1425091, we called RangeUpdater::SelAdjCreateNode() with point of
new node in EditorBase::CreateElement(). However, it was accidentally changed
to point *in* new element. Therefore, setting such DOM point causes warnings
in debug build and call of RangeUpdater::SelAdjCreateNode() must be failed
since the point stores wrong container node.
Additionally, this patch stops using another EditorRawDOMPoint instance which
is just redundant and renames |ret| to |newElement| for making its meaning
clearer.
MozReview-Commit-ID: Gc0YgaNLYcx
--HG--
extra : rebase_source : c2fbe2669ca8a5993e26b357f53dc38341fd6bf6
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : b89698f4ab56fdd97a4cd8c515a8b33f6a74a7af
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Boris Zbarsky
Masayuki Nakano
Dorel Luca
Chris Peterson
Makoto Kato
Xidorn Quan
Kris Maglione
Cosmin Sabou
shindli
Emilio Cobos Álvarez
Doug Thayer
Nika Layzell
Andrew McCreight
Sebastian Hengst
Tristan Bourvon
Jonathan Watt
Nicholas Nethercote
Ciure Andrei
Neil Deakin
Bogdan Tara
Andreea Pavel
arthur.iakab
Gurzau Raul
Sylvestre Ledru
Tiberius Oros
Olli Pettay
Florian Quèze
Adrian Wielgosik
Hiroyuki Ikezoe
Tim Nguyen
Narcis Beleuzu
Eric Rahm
Cameron McCormack
Brindusan Cristian
Masatoshi Kimura
Andrea Marchesini