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
Remove insertElement from TextEditRules due to unused. Also, comments into TextEditRules is out of date. We should update it using currect enum.
MozReview-Commit-ID: B1wczFWh2Ya
--HG--
extra : rebase_source : 910338b2f5d20316dcf11928e964346fa4aa8411
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
IsTextNode is static method, so we should use explicitly static method call into EditRule.
MozReview-Commit-ID: EX2BbbN2vNJ
--HG--
extra : histedit_source : 4194477320ffad62da36b272239d1443bb6c88b6
Most codes into HTMLEditRules and TextEditRules don't use explicitly static method call such as EditorBase::GetStartNodeAndOffset. So we should use it instead of "editor->GetStartNodeAndOffset".
MozReview-Commit-ID: DGAEFK6AYzh
--HG--
extra : rebase_source : d1dafaca2dbe95d9b1c50c52245f29af75e0a9f2
extra : amend_source : c183380253a1cf5c1dbc1cf18eb70e26ca0cadeb
We can replace old nsIEditor API with nsIAtom version.
MozReview-Commit-ID: EMEANldtTo0
--HG--
extra : rebase_source : 2828270d42efe1786f88f13bf20c34bd56083d41
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
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
