This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This patch makes EditorBase derived from nsISelectionListener. Then, we can
make IMEContentObserver, TextInputListener, ComposerCommandsUpdater,
TypeInState not derived from nsISelectionListener since EditorBase or
HTMLEditor can notify them of selection change directly. Additionally,
ResizerSelectionListener is not necessary anymore since it just implements
nsISelectionListener and calls only a method of HTMLEditor. So, HTMLEditor
can call it directly.
Note that the order of selection listeners may be different. However,
according to what each selection listener does, changing the order isn't
problem.
MozReview-Commit-ID: 1JXZxQcS0tP
--HG--
extra : rebase_source : c2ebe622a74001ad4e421da492dcdab8e6fe1649
For making ComposerCommandsUpdater not derived from nsISelectionListener,
HTMLEditor needs to store it directly.
This patch also makes ComposerCommandsUpdater cycle collectable because it
stores a strong pointer and HTMLEditor also needs to store it with RefPtr.
Therefore, ComposerCommandsUpdater becomes unnecessary to use nsWeakPtr.
MozReview-Commit-ID: 2WZnLdq15FK
--HG--
extra : rebase_source : 8ee4968e1a63fe88a8276b1f8ce8d145fb9b31ae
For making HTMLEditor stores it directly, we should expose
nsComposerCommandsUpdater first. Then, it should be in mozilla namespace.
MozReview-Commit-ID: 8Vhum4Q3WY
--HG--
rename : editor/composer/nsComposerCommandsUpdater.cpp => editor/composer/ComposerCommandsUpdater.cpp
rename : editor/composer/nsComposerCommandsUpdater.h => editor/composer/ComposerCommandsUpdater.h
extra : rebase_source : 3056eeb4aa3dd3426246b74be1e1e18a93a7c33d
Currently, first edit action listener is always TextServicesDocument for
EditorBase::mInlineSpellChecker if spell check is enabled and it requires
only DidDeleteNode() and DidJoinNodes(). So, in most cases, EditorBase
should call only them to avoid running redundant for loops for
nsIEditActionListener methods.
This patch makes that EditorBase::AddEditActionListener() and
RemoveEditActionListener() check whether coming nsIEditActionListener is
TextServicesDocument for mInlineSpellChecker. If so, EditorBase should
store it as reference to TextServicesDocument. And when edit action occurs,
its DidDeleteNode() and DidJoinNodes() should be called directly.
Unfortunately, this patch makes TextServiceDocument's maintaining rules
complicated. However, it must be really rare case to add new edit action
listener because it's really old component.
Note that EditorSpellCheck may be created multiple instances for an editor
from chrome JS. Therefore, we need to keep TextServicesDocument being
derived from nsIEditActionListener because in such case, TextServicesDocument
for other EditorSpellCheck instances should be supported via
nsIEditActionListener even though such case makes EditorBase slower.
MozReview-Commit-ID: KtlXsBCOzKL
--HG--
extra : rebase_source : 6827ed09a028f2049fd7afba2f5116d092bd14e5
mozSpellChecker stores TextServicesDocument, EditorSpellCheck stores
mozSpellChecker and mozInlineSpellChecker stores EditorSpellCheck.
So, they should have accessors for their member. Then, EditorBase can
access all of them.
MozReview-Commit-ID: Igphm8nRqve
--HG--
extra : rebase_source : 0c70bf3e23f16ea6a97b49901f4b1c87e7da6d37
For making mozInlineSpellChecker stores nsEditorSpellCheck directly, we need
to expose its header file. For doing that this patch renames the class to
mozilla::EditorSpellCheck and expose it as "mozilla/EditorSpellCheck.h".
MozReview-Commit-ID: 5H66Y2vVshu
--HG--
rename : editor/composer/nsEditorSpellCheck.cpp => editor/composer/EditorSpellCheck.cpp
rename : editor/composer/nsEditorSpellCheck.h => editor/composer/EditorSpellCheck.h
extra : rebase_source : 7940aa136df312cd43bf592df1e71d2ac6c5dec8
nsEditorSpellCheck::mSpellChecker is always mozSpellChecker because it's
created only by nsEditorSpellCheck. Additionally, mozSpellChecker.h is
already exposed. So, nsEditorSpellCheck can store it as mozSpellChecker
directly.
MozReview-Commit-ID: 2vyDe4plncM
--HG--
extra : rebase_source : 847b2f384163450ab44b94bc12ee489633a849b6
nsITextServicesDocument isn't used by anybody now. So, we can get rid of it.
Additionally, nsITextService and nsTextServicesFactory are not also used by
anybody. Therefore, this patch removes all of them.
MozReview-Commit-ID: KSbMdm7QPKF
--HG--
extra : rebase_source : 724a5f48ad49b4231bacf7fba32c6a35d90121d0
Now, TextServicesDocument can be treated by anybody. So, let's make
mozSpellChecker and nsEditorSpellChecker treat it directly instead of
nsITextServicesDocument.
MozReview-Commit-ID: 2tMy6y3i17b
--HG--
extra : rebase_source : 2e6c79355a5e0a7044fbea989ba414a7bf1a7d8d
Actually, PopItem uses nsString to store attribute name. And when using it,
it converts to nsAtom by NS_Atomize and compare by nsString.
To reduce calculation of atom and string compare, we should store atom directly.
MozReview-Commit-ID: 8OB02mgMg1r
--HG--
extra : rebase_source : 9861217804acac52106a89cad75e08bd547080ad
extra : histedit_source : 2b9f01cf29b1b09dd07fc771ff94a06be4d94f31
nsIEditorSpellCheck still uses wstring. We should replace it with AString
to avoid additional memory allocation.
MozReview-Commit-ID: H4jKY2tylqg
--HG--
extra : rebase_source : c1f0325eb2efbfb07f53514b96121a5ceb58efd4
libpref only allows pref modifications in the parent process. This patch
tightens up the checking, which is a bit inconsistent.
- It removes ENSURE_MAIN_PROCESS_WITH_WARNING, which does NS_WARNING on
failure, and replaces its uses with ENSURE_MAIN_PROCESS, which does NS_ERROR
on failure. This required adding an XRE_IsParentProcess() check to one place
in editor/.
- It converts XRE_IsContentProcess() tests to !XRE_IsParentProcess(), because
we now have multiple kinds of non-parent process.
- It uses ENSURE_MAIN_PROCESS to replace other checking code in a few places.
- It improves a comment in HandleDirty().
MozReview-Commit-ID: D8znQWH7ery
--HG--
extra : rebase_source : ea0fc095b31525bde82a1be217923512d030b76d
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
When using contenteditable with spellchecker (it is by default), spellchecker will be initialized by mozilla::EditorEventListener::Focus. This method will call nsEditorSpellCheck::UpdateCurrentDictionary, but this method seems to be slow.
DictionaryFetcher::Fetch gets nsIContentPrefService2 that is implemented by JavaScript, so we should create nsIContentPrefService2 out of Fetch method.
MozReview-Commit-ID: 1fxug0sqD72
--HG--
extra : rebase_source : c46a54f9fc811aace20c54c4a3e468a83c2530d2
I would like to remove more dependency of old nsISelection interface from editor if possible. So we can replace nsISelection::GetRangeCount with Selection::RangeCount.
MozReview-Commit-ID: 2Mh5ceQI2om
--HG--
extra : rebase_source : 03c8a5b49e2929b0ce6c6af8b78c9677a55a14c4
extra : histedit_source : ca7741379c7cc5b7b938aad22a57f419a2442fd3
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
These are all simple cases, with similarities to previous patches in this
series.
--HG--
extra : rebase_source : 6ef36382df9fef217d5cb737e218d65ac062f90a
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
nsIHTMLDocument::TearingDownEditor() takes nsIEditor as an argument. However, it's not used in it. So, we can remove it.
MozReview-Commit-ID: KUmIsnVGB6H
--HG--
extra : rebase_source : ddd344b9df18e0b33d54d2f99e6335449f55df81
nsEditingSession should treat editor as HTMLEditor in its internal handling.
MozReview-Commit-ID: 51SfY4oeq3p
--HG--
extra : rebase_source : 90535267e62de17755fff9f21b6a0f74244d849a
Some users of HTMLEditor retrieve pointer to editors with nsIEditingSession::GetEditorForWindow() but it returns nsIEditor. So, there should be a method which returns HTMLEditor*.
MozReview-Commit-ID: Bzc1LIlTSDF
--HG--
extra : rebase_source : f6fb3e5852809487883e3e6fedda9580206b2cb5
nsComposerCommands uses some simple getter methods. They can be simpler non-virtual methods. So, we should do it.
Note that this changes that EditorBase::GetIsSelectionEditable() won't return error. However, it has returned error only when selection controller isn't available. That means that the selection controller has been destroyed and the editor will be destroyed. So, this must not be problem since it returns false (non-editable) instead and won't break any behavior since the editor won't be editable by users nor JS anymore.
MozReview-Commit-ID: E9ccFspG6na
--HG--
extra : rebase_source : bcd1314cb386fcaf175adabfefde5885decd87c0
Compiler may can optimize to call virtual methods at build time if we call them with concrete classes because some of them may have final keyword.
Even if not so, we can optimize some methods with creating non-virtual methods.
MozReview-Commit-ID: K3bRlc0URml
--HG--
extra : rebase_source : 4a76635c7aed29501f71ae74f3f73e2b22ca219e
All SetState() methods in nsComposerCommands require HTMLEditor. So, it should take HTMLEditor* rather than nsIEditor*.
MozReview-Commit-ID: AVbnRsMsmeY
--HG--
extra : rebase_source : 23bcc585a045a39620102c4fef9c1a9e12b9ea37
Similar to GetCurrentState(), all ToggleState() methods require HTMLEditor. So, they should take HTMLEditor* instead of nsIEditor*.
MozReview-Commit-ID: BwM6WRKFn6Q
--HG--
extra : rebase_source : 425b7b405b5881b97e8113c3ab88e9d0514b6a07
All GetCurrentState() methods in nsComposerCommands require HTMLEditor but its argument is nsIEditor*. So, it should take HTMLEditor* and it shouldn't be called if given editor isn't HTMLEditor since it's virtual method.
MozReview-Commit-ID: HsvYJN8hIxN
--HG--
extra : rebase_source : f8f9c8de902af5311771b71a96c76d63325970a5
If we make nsIEditor a builtin class, that means that its instance can be only TextEditor or HTMLEditor. Then, users of nsIEditor can use concrete classes such as EditorBase, TextEditor or HTMLEditor instead. Then, the users can reduce unnecessary QI and a lot of virtual calls if we'll create non-virtual methods.
So, let's make editor related interfaces builtin classes.
MozReview-Commit-ID: 93WfsSDuJiJ
--HG--
extra : rebase_source : 39151eb4ffaaf195fec57234ea84c9f4066c58d1
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
This patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
