The target node of HTMLEditRules::ReapplyCachedStyles() may be styled with its parent. When HTMLEditRules::ReapplyCachedStyles() is called, it shouldn't restore another style cache if it's already specified in current DOM tree.
MozReview-Commit-ID: DKCpQ8YyW7
--HG--
extra : rebase_source : 854b4cc6382f5357919bce1e106e71fe66b15444
Now, nobody (including add-ons) uses nsIHTMLEditor::SetDocumentTitle(), so, we can remove it.
Additionally, mozilla::SetDocumentTitleTransaction is created only when nsIHMLEditor::SetDocumentTitle(), so, we can remove this class too.
MozReview-Commit-ID: HK7G9u7HUlh
--HG--
extra : rebase_source : da68cabbf929a684d26f6316fdc7f58b8e32ab02
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
We have no mochitest for objectResizing and inlineTableEditing. So I add simple test for this.
MozReview-Commit-ID: Hnjpopr3h5F
--HG--
extra : rebase_source : 8cb81a89f11d4092f2adaa8822733f861a71ace1
When selection is collapsed and JoinBlocks() doesn't handle nor cancel the action, WillDeleteSelection() should move selection to the start/end of leftmost/rightmost editable leaf node and retry to handle the action again.
For avoiding infinite loop, it checks if selected node is changed actually before calling itself again.
MozReview-Commit-ID: GtEC4dim3r9
--HG--
extra : rebase_source : f84afd754e71f441c3fad15456d20a11c42dd6de
The test compaires 4 screenshots for checking spellchecker's behavior. However, the input element is sometimes not painted correctly on Linux.
Even if I make it wait more delay before taking screenshot, the random failure isn't fixed. So, I guess that it's a bug of gfx of Theme API of GTK.
On the other hand, the most important thing here is, compairing the foreground contents of the input element. Therefore, this patch makes the background and border of the input element transparent. That prevents to use Theme API. This must be enough for fixing the random orange.
MozReview-Commit-ID: L2uXcPLvbNg
--HG--
extra : rebase_source : 451f1c45d70ceb8406ea9749f0dfa3264c615151
We need skip this test on Android. Although mochitest doesn't use native IME data, Android's GeckoEditable.java wants to access native IME composition. See bug 1315898.
MozReview-Commit-ID: BNCKmDEmwKw
--HG--
extra : rebase_source : e7be1cb9e5c7c0fb4283f81541fc7441f52a1101
Currently, when selection is collapsed at an empty text node, the behavior of each major browser is different.
When you remove the last character of non-empty text node followed by empty text nodes, Chromium removes all following empty text nodes. However, Edge never removes empty text nodes even when selection is collapsed at an empty text node.
With this patch, our behavior becomes same as Edge. I think that we should take this for keeping backward compatibility since Gecko never removes empty text nodes. So, in other words, this patch makes Backspace key press at an empty text node modify the preceding non-empty text node.
When you remove the first character of non-empty text node preceded with empty text nodes, Edge removes all preceding empty text nodes. However, Chromium and Gecko keeps previous empty text nodes than caret position. So, we should keep current behavior for backward compatibility. In other words, this patch makes Delete key press at an empty text node modify the following non-empty text node and keep current behavior.
The fixing approach of this is, making WSRunObject::PriorVisibleNode() and WSRunObject::NextVisibleNode() ignore empty text node. This should make sense because empty text node is not a visible node. (On the other hand, when the DOMPoint has a null character, it should treat as visible character. That is visible with Unicode codepoint.)
MozReview-Commit-ID: 11YtqBktEvK
--HG--
extra : rebase_source : 70fa858866cc768179c1ca6a869e1a5c7cfe6e1a
Even when editor receives eCompositionStart event, the active composition may have gone since web contents can listen to composition events before editor (so, web contents can commit the composition before "compositionstart" reaching focused editor).
Therefore, editor shouldn't crash as unexpected scenario. Instead, it should do nothing in such case.
Note that when editor receives 2nd or later "compositionupdate" or "text" event, it should not modify composition. However, currently, it does that. This patch does NOT fix it since it's really rare case. It should be fixed in another bug because this should be uplifted (crashing with some IMEs on Android is serious).
MozReview-Commit-ID: HIbMy4eFRMw
--HG--
extra : rebase_source : a98661ab2c1c8ee67ef551af3d1770b61cd25c84
The change from ok() to is() in tests is so that the failure message is
more informative -- it now tells you the returned exception.
This commit omits test_contenteditable_text_input_handling.html because of test
failures that I haven't figured out.
MozReview-Commit-ID: 37cYlQlJZm7
I added an extra check to ensure that the test wasn't passing because
doCommand() was throwing some unrelated exception, in case porting from
chrome to plain changed behavior of doCommand().
MozReview-Commit-ID: LOo8yN8jkZo
Possible issue: the previous version saved document.popupNode and
restored it after copying the image, and the new version does not
(because I don't know how). The test seems to pass anyway.
MozReview-Commit-ID: 7g0JCYxI7x8
--HG--
rename : editor/libeditor/tests/test_bug1140617.xul => editor/libeditor/tests/test_bug1140617.html
Possible issue: the previous version saved document.popupNode and
restored it after copying the image, and the new version does not
(because I don't know how). The test seems to pass anyway.
It seems I had to use doCommand instead of execCommand to carry out the
paste, presumably because of permissions differences between plain and
chrome mochitests.
MozReview-Commit-ID: CdPUCmEtgwO
--HG--
rename : editor/libeditor/tests/test_bug490879.xul => editor/libeditor/tests/test_bug490879.html
Filed bug 1299574 for the Android todo. (Chrome tests in this directory
are disabled for Android, so all this porting enables them.)
MozReview-Commit-ID: 6FAioabxq0a
--HG--
rename : editor/libeditor/tests/test_selection_move_commands.xul => editor/libeditor/tests/test_selection_move_commands.html
