Since current selection ranges might be modified by SplitStyleAboveRange, this crash occurs into RemoveInlinePropertyImpl. So we need hold current selection range for loop.
MozReview-Commit-ID: JuXn9XlwCp6
--HG--
extra : rebase_source : f34cd77d19c1a8bfcc6e26c6f0b1cd833ce4b19e
There is a lot of string compare when using CSS property name. We should use nsGkAtoms instead.
MozReview-Commit-ID: JvpWRTkM8U
--HG--
extra : rebase_source : 404518a52fdab6b64a804835acd1ea16b5adde7c
EditorBase parameter of GetTextNode is unnecessary because it uses static method only. Also, we should return nsINode to reduce QI.
MozReview-Commit-ID: 3KazYFcr899
--HG--
extra : rebase_source : 092bbcc84d7c1e7174029bb90f606f3953fe8597
c-c nor add-ons seem noet to use it. We should remove this.
MozReview-Commit-ID: 3jN8kUp6D4Z
--HG--
extra : rebase_source : cc31001bb87da2888a9c1da6d92a305cdebebb7a
Resizer and etc attributes on table editor still use nsIDOMElement. Converting to Element makes both implementation and the callers simpler.
MozReview-Commit-ID: TTFSvqn5GE
--HG--
extra : rebase_source : 705576c4eb0fe5f8f566f3415a8a72842c919edd
Now we can return Element directly via CreateAnonymousElement. We should use it.
MozReview-Commit-ID: Et1i3hLVSqc
--HG--
extra : rebase_source : e09c2b2b41481dd6608d9c816676030d8aae1ed6
I would like to nsIAtom and mozilla::dom::Element version of CreateAnonymousElement to clean up code. When getting/setting attirubte, editor sometimes use string, not nsGkAtoms. We should use new mozilla::dom::Element methods.
Also, we should add _moz_anonclass to atom list that uses on editor.
MozReview-Commit-ID: ICaAWVPjcej
--HG--
extra : rebase_source : 9585214aa678c16905250265a75b817c90246fcc
We have no mochitest for objectResizing and inlineTableEditing. So I add simple test for this.
MozReview-Commit-ID: Hnjpopr3h5F
--HG--
extra : rebase_source : 8cb81a89f11d4092f2adaa8822733f861a71ace1
For now, let's make the scope of EditActionResult variable in them smaller without big change.
MozReview-Commit-ID: 9vDoU9bUdVO
--HG--
extra : rebase_source : 6cdd50954d6cfe1fa80aeee5b06b3fec6b1ada3d
In a lot of places, edit action handlers and their helper methods return nsresult and aHandled and aCanceled with out params. However, the out params cause the code complicated since:
* it's not unclear if the method will overwrite aHandled and aCanceled value.
* callers need to create temporary variable event if some of them are not necessary.
This patch rewrites the helper methods of HTMLEditRules::WillDeleteSelection() with it.
MozReview-Commit-ID: CJv75KdOdXf
--HG--
extra : rebase_source : 708d378bdd0ddc4ae984de9294525b01a829b0b7
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
When HTMLEditRules::WillDeleteSelection() tries to remove something from the end/start of a block to its last/first text node but it's contained by block elements, it tries to join the container and the block. However, JoinBlocks() always fails to join them since it's impossible operation. In this case, HTMLEditRules::WillDeleteSelection() should retry to remove something in the leaf, however, it's impossible for now because JoinBlocks() and its helper methods don't return if it handles the action actually.
This patch renames |JoinBlocks()| to |TryToJoinBlocks()| for representing what it is. And this patch adds |bool* aHandled| to the helper methods. Then, *aHandled and *aCancel are now always returns the result of each method. Therefore, for merging the result of multiple helper methods, callers need to receive the result with temporary variables and merge them by themselves.
Note that when they modify DOM node actually or the action should do nothing (for example, selection is across tables), aHandled is set to true.
MozReview-Commit-ID: 7ApUOgtLUog
--HG--
extra : rebase_source : 4abc1ec208107b782a719df058623fd7f92d180c
If not text node, QI to nsIContent will be failed. So we should use IsNodeType (Or EditorBase::IsTextNode) without QI for detection of text node.
Also, to get content length into text node, we should use TextLength() simply instead of getting content string. It can reduce memory allocation.
MozReview-Commit-ID: C8EKxfUBjTP
--HG--
extra : rebase_source : 30614bd21393f96f9a9b13aeb5a742fa8c6eb83f
extra : amend_source : 8b956f9fbd521f7c9503bdb5481694579cb6e3e9
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
Although GetGoodSelPointForNode only supports ePrevious or eNext as action, we use other action. So we should add aseetion for it.
MozReview-Commit-ID: 3gLFFTAdNxU
--HG--
extra : rebase_source : b22cd532b6072e19fe1bff7f90a0e4a4ae4236e1
extra : histedit_source : 117509f1b76a382e8b23c5fa3345b81460385e56
When using CompositionTransaction, text node will be inserted into IMETextNode, not aTextNode of parameter. So we should use it for listener.
MozReview-Commit-ID: 72a3ZjF1wsz
--HG--
extra : rebase_source : 325909c0d141c238ab41e33d7f3959f4db27339e
extra : histedit_source : 52d6fc9d2668e4e41783e524276d7041eec0301c
Although PlaceholderTransaction will use the selection on Merge, it is too late to use UpdateRange. Because RangeUpdater will be used after DoTransaction is finished. So we should update selection on DoTransaction.
Also, part 1 fix doesn't update selection correctly via RangeUpdater when IME composition is multiple node.
MozReview-Commit-ID: 9so9tR8uQ6t
--HG--
extra : rebase_source : 02a8bebe6c89ceb023bd598b77b40c5817cd4007
extra : histedit_source : d114420552779d3352637c5554bf9e90e6e9cd40
Since the selection into PlaceholderTransaction isn't updated via RangeUpdater, UndoTransaction may return error when selection/caret position is changed. Then, redo is failed.
So we should add selection into PlaceholderTrancation to RangeUpdater.
MozReview-Commit-ID: LcUIiUExNhx
--HG--
extra : rebase_source : 9e1a71a7f497181171209ac05edcbddae227ab93
extra : histedit_source : 200dfd7957bf1b4dc92af72bb8b864cb457d62ab
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
Google Keep uses range.insertNode on input event. So, text node will be inserted into current caret position.
Microsoft IME's caret is after composition string, but ATOK's caret is before it. So when using ATOK, this issue occurs. By range.insertNode, text nodes that have IME attribute becomes multiple text nodes. But CompositionTransanction doesn't consider that IME range isn't single text node. Although it replaces current composition string with new string on first text node, it doesn't delete composition string on other text node.
MozReview-Commit-ID: 9uRx0A9mppx
--HG--
extra : rebase_source : fe0754cee2197822ca6ac9ebed13013a8f13b606
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
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
--HG--
extra : rebase_source : f9dcc6b06e9ebf9c30a576f9319f76a51b6dc26f
Giving '0' (literal zero) to RefPtr is now ambiguous, as both
RefPtr(decltype(nullptr)) and RefPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: A458A4e9for
--HG--
extra : rebase_source : bc4107ce1767329e3dddfe34c55ba79202192e06
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
Carsten "Tomcat" Book
Cameron McCormack
Makoto Kato
Jorg K
Gijs Kruitbosch
Karl Tomlinson
Olli Pettay
Andi-Bogdan Postelnicu
Ryan VanderMeulen
Masayuki Nakano
Benjamin Smedberg
Boris Zbarsky
SkyLined
Gerald Squelart
Neerja Pancholi
Phil Ringnalda
Sebastian Hengst
Jessica Jong