mozEnglishWordUtils should be deXPCOM since it isn't used from script, then get
rid of mozISpellI18NUtil that is unused.
MozReview-Commit-ID: JpRuWfu3uYx
--HG--
extra : rebase_source : 4094e5566db84110599567df49e7f3925a08a7e9
Some methods in mozISpellI18NUtil are unused now.
MozReview-Commit-ID: Ku9FojuJW3T
--HG--
extra : rebase_source : a6c3afc7c7b116c1ba2c71bd93744f2ee8c724c2
No one uses mozISpellI18NManager, so we should get rid of this interface.
MozReview-Commit-ID: 7f0Cy3tHnt1
--HG--
extra : rebase_source : 414c81cd4bec07124a271138e60ca3fb62ccc439
mozISpellI18NManager is only used to get mozISpellI18NUtil. And
mozISpellI18NUtil is only implemented on mozEnglishWordUtils. So we should
create an instance of mozEnglishWordUtils instead of using mozISpellI18NManager.
MozReview-Commit-ID: FmCuMAMmH9C
--HG--
extra : rebase_source : fe4bf18f5a3ed6b595185dcaa4a51b83f2f0d8b6
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
Differential Revision: https://phabricator.services.mozilla.com/D1869
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 6372b2681a59d267f966e9fa2ca9a54e3ff0cea0
extra : intermediate-source : b11aa832c41ac5beef9065f804d11fb7c9887990
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 1e72949e4e1012025ccf87642cc239ea5f15217d
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 53dc0c682bf61d5135fbca172ac5238b414a1771
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
Our bundled Hunspell now significantly differs from upstream Hunspell. Most
importantly, it supports loading dictionaries from jar: URIs, which is now a
requirement for loading bundled and extension dictionaries. This means that
system Hunspell libraries are no longer compatible with our spell checker
code. We should remove the option to use them so that users don't fall into
the trap of trying to use them.
MozReview-Commit-ID: 2ihJe6YOnGf
--HG--
extra : rebase_source : ceb091b9475a2b101156405a02a60015fc36da17
It is unnecessary to keep virtual method for
mozInlineSpellChecker::SpellCheckAfterEditorChange, so we should remove virtual
keyword.
MozReview-Commit-ID: 2ry5uhMTFVC
--HG--
extra : rebase_source : ba86bb7c4e47598f83e3869733a238a740cef6b2
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
This will allow us to store dictionaries in packed extension XPIs and/or
omni.ja, which should give us a significant startup performance win.
MozReview-Commit-ID: K7fzJJAywjC
--HG--
extra : rebase_source : 4022d27bc4896d8ef27d4141b6c9bc0dd9e1c0a0
extra : absorb_source : 04bdcab8ff8005a0537d1747ba52e84946e7806a
The work to migrate to Sqlite.jsm seems to have caused a timing problem
in our tests where shutdown the content process while this IPC message
is still unresolved. This causes us to destroy RemoteSpellCheckingEngineChild
without it having processed its RecvNotiy..., leading to the promise being
leaked. As far as I can tell this resolves all of our leak issues on try.
MozReview-Commit-ID: GdwVIp5dj1m
--HG--
extra : rebase_source : b7bf5838c53e40b49bea17df123028a2dbd26e5e
Without XPCOM and related method, I want to remove dependencies of nsIDOM*
from spellchecker. Also, it is unnecessary to use nsISelectionPrivate since
we can use mozilla::dom::Selection instead.
MozReview-Commit-ID: 1Zheq3Hsepj
--HG--
extra : rebase_source : 593134f0120cc0806e63253c586e384871463414
According to existing comments, TextEditor::TypedText() and
HTMLEditor::TypedText() are intentional bottleneck to debug. However, only
for that purpose, it and its internal methods are made virtual. This really
doesn't make sense.
So, this patch creates TextEditor::OnInputText() for callers of TypedText()
with non-empty string, TextEditor::OnInputParagraphSeparator() for callers
of TypedText() with eTypeBreak (Enter key or insertParagraphSeparator),
HTMLEditor::OnInputLineBreak() for callers of TypedText() with eTypeBR
(Shift + Enter or insertLineBreak). Additionally, this creates internal
non-virtual methods for XPCOM methods which are used as internal methods of
TypedText(). One is InsertTextAsAction() for nsIPlatintextEditor.insertText().
the other is InsertParagraphSeparator() for nsIPlaintextEditor.insertLineBreak().
Although those new methods are not have "WithTransaction" postfix, they must
be clearer they'll use transactions since user input and actions should be
undo-able.
MozReview-Commit-ID: AmOkMqovIKA
--HG--
extra : rebase_source : 9c0f4b25fa2a36ad2f3394f72eb290824c31d82a
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
Adds a new TYPE_SPECULATIVE to nsIContentPolicy uses it as the type for
speculative connection channels from the IO service. I believe I've added it to
all the content policies in tree to make sure it behaves the same as TYPE_OTHER
used to.
The webextension test shows that the webextension proxy API sees speculative
lookups requested through the IO service.
MozReview-Commit-ID: DQ4Kq0xdUOD
--HG--
extra : rebase_source : d9460fdac118bc68f0db79749a16f181b580f2e7
The GetSelection changes are so we have a Selection that we can get an nsRange
from via GetRangeAt, so we can call nsRange::CloneRange.
MozReview-Commit-ID: 6rqdJ29Yyuc
I got a bit carried away with fixing up consumers to use nsINode... But as a
result removing these methods all together made sense.
MozReview-Commit-ID: 2z9Q6D7GY92
It is unnecessary to use already_AddRefed for GetDocument and GetPresShell.
Then, if we remove already_AddRefed, we can replace this with const method.
MozReview-Commit-ID: KTVS0rYrY2i
--HG--
extra : rebase_source : 0199026410fc674f112c960b599a09bc7906cf85
This is follow up for bug 1430785. We should initialize
mIsListeningToEditActions on constructor.
MozReview-Commit-ID: 63Igswp3GX1
--HG--
extra : rebase_source : f06b4e650069627de4b23fb1abf30c64a3bb99fd
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
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
mozInlineSpellChecker listens to only DidSplitNode() and DidJoinNodes().
So, EditorBase should call them directly rather than treating it as an
nsIEditActionListener since its runtime cost becomes really cheaper.
Different from EditorSpellCheck, nobody creates instance of
nsIInlineSpellChecker. So, we can now stop supporting createInstance() for it
in chrome JS and should do this since EditorBase cannot support multiple
mozInlineSpellChecker instances without nsIEditActionListener interface.
Therefore, this patch removes the entry from factory.
MozReview-Commit-ID: W1CLdsJaaB
--HG--
extra : rebase_source : 2319999e4b1fc8978386c49236d5d24d78d86047
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
EditorBase::mInlineSpellChecker is always an instance of mozInlineSpellChecker.
Fortunately, it's easy to expose mozInlineSpellChecker.h. So, making EditorBase
store it as mozInlineSpellChecker directly, EditorBase can access any of
mozInlineSpellChecker, EditorSpellCheck, mozSpellChecker and
TextServicesDocument with new accessors created by following patch.
MozReview-Commit-ID: 2oyS5tPeQcg
--HG--
extra : rebase_source : a9ce2e4dbceff7ca800d34d60d56eba184298677
mozInlienSpellChecker::mSpellCheck and mozInlineSpellChecker::mPendingSpellCheck
are always instances of EditorSpellCheck because mozInlienSpellChecker creates
its instance. Therefore, making mozInlineSpellChecker store EditorSpellCheck
directly makes sense.
MozReview-Commit-ID: LTtEMZqMS9E
--HG--
extra : rebase_source : 94e4c4ada332e626d49de5782fca192fb7489064
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
For making nsTextServicesDocument accessible from anywhere directly, we need to
expose its header. Then, it should be in mozilla namespace.
This patch renames nsTextServicesDocument to mozilla::TextServicesDocument
and expose the header file as "mozilla/TextServicesDocument.h".
MozReview-Commit-ID: 9PmP73PXSJu
--HG--
rename : editor/txtsvc/nsTextServicesDocument.cpp => editor/txtsvc/TextServicesDocument.cpp
rename : editor/txtsvc/nsTextServicesDocument.h => editor/txtsvc/TextServicesDocument.h
extra : rebase_source : a12081434d0bc002e3675178486cc7f8eaaa3256
Most nsIEditActionListener::Will*() are not implemented, except
WillDeleteText() and WillDeleteSelection() which are implemented by
FinderHighlighter. So, we can get rid of the other Will*() from it.
This patch removes a lot of unnecessary virtual calls and copy of strong
pointers to edit action listeners of EditorBase.
MozReview-Commit-ID: EsqI2tZoBG1
--HG--
extra : rebase_source : cf78eb8d33b12ca65177b0676f6e45d02e7c0688
For calling some methods of mRules from EditorBase, let's move mRules member
from TextEditor to EditorBase.
Unfortunately, TextEditRules.h depends on EditAction which is declared in
EditorBase.h and that caused unnecessary include hell of EditorBase.h. So,
let's move it to an independent header file.
MozReview-Commit-ID: 5HiSZLP9WHH
--HG--
extra : rebase_source : 3e2c40385a6f3d6d1e03ef4e213434383bb37d5f
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
nsIEditorSpellCheck still uses wstring. We should replace it with AString
to avoid additional memory allocation.
MozReview-Commit-ID: H4jKY2tylqg
--HG--
extra : rebase_source : c1f0325eb2efbfb07f53514b96121a5ceb58efd4
Although nsIEditActionListener::WillInsertNode() nobody implements actually,
we should remove it in a follow up bug.
nsIEditActionListener::DidInsertNode() is implemented only by HTMLEditRules.
So, if we make it not use nsIEditActionListener, we can remove it too.
However, keep it for now.
On the other hand, they don't need to receive index of the insertion point.
WillInsertNode() needs next sibling of the insert point, but DidInsertNode()
needs nothing because listener can compute it with new inserted node.
MozReview-Commit-ID: GiTKkVyZJlN
--HG--
extra : rebase_source : 9ee38c28217d25d1a3f79b0b458c7b2121350a76
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : source : e2beba7e6875120ebbbcadf24bcbcb5b86411a94
extra : amend_source : 11f07a27431cd468511f0bd45afe36150c6e342c
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : rebase_source : 03e703a81ed4b80f4f116ff36d8787464ce5acba
No one uses nsIInlineSpellChecker.spellCheckAfterEditorChange from script.
So I think we can mark this interface as noscript.
Since this method is scriptable, we need QI to get nsIDOMNode. If we can
change to noscript, it can reduce QI to get nsIDOMNode.
MozReview-Commit-ID: GC0WuFyTlaZ
--HG--
extra : rebase_source : 16ca9fc548e86747ac17407be48295c709174fb5
nsIEditActionListner::DidSplitNode() takes 4 arguments, the right node,
old offset in the old right node before splitting, the new left node and
nsresult.
Computing offset for this doesn't make sense because it's always same as
the length of the left node. Additionally, nobody currently use nsersult.
So, we can get rid of it now.
Fortunately, nobody including comm-central and BlueGriffon implements
WillSplitNode(). So, we can get rid of it. However, removing interface
method should be done in a follow up bug. So, we can remove offset computation
in EditorBase::SplitNode() completely in the future.
MozReview-Commit-ID: JWj34SjBNJh
--HG--
extra : rebase_source : f0e1ed0e466dc8217c1a0ab1722790883a7efd1f
nsIEditActionListener::WillCreateElement() and
nsIEditActionListener::DidCreateElement() are implemented only by m-c.
So, we can remove a set of container node and offset in it from their argument.
Instead, WillCreateElement() should take a node which will be next sibling of
the new node.
Note that only implementation of them is, HTMLEditRules::DidCreateElement().
So, we can get rid of them and can call HTMLEditRules::DidCreateElement()
directly from EditorBase::CreateNode(). However, such change should be done
in another bug which checks all nsIEditActionListener method implementations.
MozReview-Commit-ID: 4LQEs2WwrVC
--HG--
extra : rebase_source : ee1bee1413c578b2873a291c712b8ef46221db0f
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
--HG--
extra : rebase_source : 725ccf57943283a60ef8c9d654afe4515b4089f8
"Nonsecure HTTP" here just means regular, not-HTTPS HTTP. It doesn't mean HTTPS without the `Secure` cookie flag. Honor the expiration time of third-party cookies set over HTTPS, whether or not they have the `Secure` cookie flag. If a third-party cookie is set over HTTPS and then later sent in nonsecure HTTP request (which is allowed for cookies without the `Secure` cookie flag), the cookie won't be turned into a session cookie unless the nonsecure HTTP response sets a new cookie value.
This feature is controlled by the pref "network.cookie.thirdparty.nonsecureSessionOnly".
MozReview-Commit-ID: HlCg21JyvNC
--HG--
rename : extensions/cookie/test/unit/test_cookies_thirdparty_session.js => extensions/cookie/test/unit/test_cookies_thirdparty_nonsecure_session.js
extra : source : d1be2e4265201efd3ee93e965ac68561f548fd05
extra : intermediate-source : f5b382fa1b70e30a907b1f10d74f8c0c6dff344e
This patch enables support for setting prefs with the pattern
permissions.default.* to provide a custom default permission
for arbitrary permission types in nsPermissionManager.
The previous default of UNKNOWN_ACTION is honored if no pref is set.
A default value is provided if no permission entry can be found in the db.
Accordingly, the patch does not affect the behavior of functions
that return permission objects from the db such as GetPermissionObject,
which returns null if no entry was found.
MozReview-Commit-ID: 3JECI6kXqGf
--HG--
extra : rebase_source : 9fbcfc740a85c02cf4245956e69ae13c8f90b5ab
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
(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 is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is used in ways that rely on the implicit conversion
to |char*|. The patch uses get() and EqualsLiteral() calls to replace the
implicit conversions.
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.)
AutoPlaceHolderBatch can take EditorBase class and its inherited class, AutoEditBatch, can be removed if we implement other constructor which doesn't take transaction name.
Additionally, nsIEditor::(Begin|End)PlaceHolderTransaction() are referred only by AutoPlaceHolderBatch. Therefore, they can be non-public methods and removed from nsIEditor interface.
Note that this patch also repalces "PlaceHolder" with "Placeholder" since it's a word.
MozReview-Commit-ID: 5dw3kcX3bOx
--HG--
extra : rebase_source : e926cc1c2ebea70eb08e43778a8b52912b559b7b
Although, this is not necessary for bug 1388269, we should fix this here since this change is really similar to what bug 1388269 tries to fix and enough simple and safe.
MozReview-Commit-ID: H68pYTBmurf
--HG--
extra : rebase_source : dfa47370232ad44e1523c94929cf50e5539b787d
Then, can reduce a lot of unnecessary virtual calls and QI.
MozReview-Commit-ID: 28JS4q2L1Vj
--HG--
extra : rebase_source : 3f7dc379a80777f05f6b4e2d2ed1e7787de03d69
mozInlineSpellChecker is a cycle collectable class. Therefore, with including mEditor to the cycle, we can make it nsCOMPtr<nsIEditor> instead of nsWeakPtr.
MozReview-Commit-ID: DAK02zbksvy
--HG--
extra : rebase_source : 5914f37a2f339a1a39b7bd2e9065a2f7d2a1ed9c
After landing bug 1205983, mPreviousDictionary is unused. So we should remove unused GetCurrentDictionary calls.
MozReview-Commit-ID: 20GAyoiEWCN
--HG--
extra : rebase_source : 6abc0e50073c836a99a699e1de8103a3faacf071
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
DOM Standard defines that offset of Range is unsigned long. However, nsRange uses int32_t to them.
This patch makes nsRange use uint32_t instead. However, this patch does NOT allow to set over INT32_MAX as offset values since a lot of users of nsRange cannot treat the values as over INT32_MAX because a lot of internal APIs take int32_t as offsets.
For easier to search such points, this patch adds static_cast<int32_t> to uint32_t variables when they are used for int32_t arguments.
And note that nsContentUtils::ComparePoints() behaves odd. It accepts negative offset and compares such value with valid offset simply. This patch still uses int32_t offset variables in nsRange::CompareNodeToRange() even though it may be negative value if nsINode::IndexOf() returns -1 because the caller of it depends on this behavior.
MozReview-Commit-ID: 8RbOgA86JuT
--HG--
extra : rebase_source : 46d526c6d50dfa2f104439b19b8691477b17a4af
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
Web standards use "Container" instead of "Parent". So, nsRange shouldn't use "Parent" for its members and methods.
MozReview-Commit-ID: Ho6N0diuWtE
--HG--
extra : rebase_source : ee4eb7068a68b118c7fe98e9e9e7fa9c9e7f13e2
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41