This is a kind of regression of bug 1088054 part 6. If new block doesn't have child node, GetLastEditableChild will return null after landing bug 1088054. So, we should use new block when GetLastEditableChild returns null.
MozReview-Commit-ID: Gzt1Xp3Sl47
***
P1
MozReview-Commit-ID: 8LVp5qGnme4
--HG--
extra : rebase_source : f0ed76b65517168b6b11edf96164b3e596038fc1
Edit transactions should store their editor instance with strong reference and they should be released at destroying the editor.
MozReview-Commit-ID: D67KU8WFxyo
--HG--
extra : rebase_source : 28c8a37498cad9f2e308eb4416cef76cf395bb9c
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
--HG--
extra : rebase_source : 513ed31d995864939aa893e73c81ffdf591a6617
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
--HG--
extra : rebase_source : 13fa4c397ba4c79303a2cd76684b5b8c4bd17331
There are no app which replaces transaction manager of editor. Additionally, replacing transaction manager of an editor with different editor or same editor but after initialized again due to some reasons may cause unexpected problems.
Therefore, this patch makes it readonly.
MozReview-Commit-ID: K7zepOjrzvC
--HG--
extra : rebase_source : ee1944af57c8102628b8cffbc720d2b8e5e9088d
I want to remove nsIDOMNodeList usages from editor excepting old debug code.
(BTW, we might have to change to <meta charset> instead of <meta http-equive>, but it should handle by another issue)
MozReview-Commit-ID: ArAVOHigKNW
--HG--
extra : rebase_source : 74ddcaa760c0cc80d6395acb3a6c9374a80dec25
extra : histedit_source : f582131f2b1d5cca8b024b0936ad04634566014e%2Ce95119c3c80903588b24fc66cd6a5b3a8e1458a9
EditorBase::CreateTxnForDeleteInsertionPoint() appends DeleteTextTransaction or DeleteNodeTransaction to the given EditAggregateTransaction. For consistency with other CreateTxnFor*() methods, this should just create a transaction and return it. Then, the caller should append the transaction to EditAggregateTransaction.
MozReview-Commit-ID: 6sqEijicFHE
--HG--
extra : rebase_source : 1443b3d9c8e90044994ad87965a26d76926e2c72
After bug 769967, FindUserSelectAllNode always returns nullptr. So we get rid of this method. Also, AreaRestriction is used by this, so it is unnecessary now.
MozReview-Commit-ID: HTc8PUCQmy5
--HG--
extra : rebase_source : 11b19a1976f6696e0d872c9020b90701dd22c8c0
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus.
If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host.
For consistency with the other browsers, this patch doesn't move focus to other focusable element.
MozReview-Commit-ID: 6sNsuzwqECX
--HG--
extra : rebase_source : 9ba52ab0bd1249abded81019847c85182ca1926e
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
Similar to DeleteNodeTransaction, DeleteRangeTransaction should take all necessary information as its arguments. However, different from DeleteNodeTransaction, this doesn't need to implement CanDoIt() since nobody checks the state.
MozReview-Commit-ID: 2Z9fNtGeJ9c
--HG--
extra : rebase_source : fe3f75126a8975a0edb00a6c0709134b0a0f4d87
I'd like to make mNodeToDelete an owning-non-null member, but it's not cycle collector aware. Therefore, this patch only changes mEditorBase from pointer to reference.
MozReview-Commit-ID: H3wxmN1t92s
--HG--
extra : rebase_source : ca9984b47c9d242f82e395773a9a7f534e60c022
EditorEventListener listens any trusted focus/blur events which may be synthesized by JS without proper event class. Then, editor will setup selection limitation. This may cause odd behavior. Therefore, EditorEventListener should stop handling focus/blur events which do not come from nsFocusManager.
MozReview-Commit-ID: 7SlfIRgArkr
--HG--
extra : rebase_source : ade7009f1b87fbc629de32b6f22a85c87c72107f
Before I will fix some justify* command's bug, I would like to clean up HTMLEditRules::RemoveAlignment to get rid of nsIDOM* into this method.
MozReview-Commit-ID: 4UATycS5iBl
--HG--
extra : rebase_source : 7079a774b4b8359aeffbdbdf2efe0b45bd92c173
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
When selected nodes are <span style="font-weight: normal;">A</span>, toggle bold inserts new span element into parent node like <span style="font-weight: bold;"><span style="font-weight: normal;">A</span><span>. So bold isn't applied correctly.
IsCSSEquivalentToHTMLInlineStyleSet might return false even if style is applied. Because it returns true that style isn't default value. Since "font-weight: normal" is default property, it isn't removed.
So when style is already applied even if it is default value, we should remove it.
MozReview-Commit-ID: LgImkHRp9Ff
--HG--
extra : rebase_source : dd4d894495754a81abaf5a2aede1132056920beb
extra : histedit_source : 72d196cd9f90296eb00b97c1538704c714cc871c
