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
Emilio Cobos Álvarez
Boris Zbarsky
Makoto Kato
shindli
Andreea Pavel
arthur.iakab
Masayuki Nakano
Gurzau Raul
Sylvestre Ledru
Tiberius Oros
Olli Pettay
Sebastian Hengst