This patch adds a `mozIStorageConnection::defaultTransactionType`
attribute that controls the default transaction behavior for the
connection. As before, `mozStorageTransaction` can override the default
behavior for individual transactions.
MozReview-Commit-ID: IRSlMesETWN
--HG--
extra : rebase_source : fc63af108bb246bc096cb9ef7c13b41fabba5563
Because of the storage::Service's connection list, it's possible for the
refcount for a non-main-thread Connection to experience transient increases
and decreases at any time, dooming logic in Release() that assumes the
refcount isn't changing.
This patch adopts use of an Atomic<bool> so that we execute cleanup logic
exactly once when the refcount falls to 1 at some point. Care is taken to
ensure that the failsafe Close() occurs on the correct thread.
SpinningSynchronousClose() is still dangerous and can still potentially
nest deeply on the stack. If we see instances of that in the future, we
may want to adopt use of PushEventQueue so that we can avoid re-entrancy
in our event loop spinning.
MozReview-Commit-ID: A835HBec50H
--HG--
extra : rebase_source : af2f63e8f050b7a0275e39f73e59133958e29f19
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
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
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
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
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 lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
NS_ProxyRelease will immediately release the provided reference if already on
the right thread unless aAlwaysRelease=true (the default is false). We need to
set it to be true to avoid Close() and its potential to, out of desperation
when faced with misuse, spin a nested event loop.
--HG--
extra : rebase_source : 91c70a6fa081fdf20a8dfabf5d69bccbef1ba33c
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
This is for the trunk/nightly landing only, and approval was explicitly
requested from #sheriffs to land without tests as a preliminary stop-gap.
Tests and a proper fix will land as part of bug 1389660, but that will be a few
days.
--HG--
extra : rebase_source : 5849f2f37d735387e13ac0486f1fae7906725111
extra : source : 908a4bb55a039985473e1565d88abebfe024c44c
The observer references were the only thing guranteed to keep the Service
alive, leading to potential use-after-free during the iteration loop to
make sure all the connections were closed. (Ironically, if they were
fully closed and their instances destroyed, that's when bad things would
happen.)
--HG--
extra : rebase_source : 6c8d6f9e0b75751b10166d7e2c63d5a3cb27d28e
This patch parameterizes nsAuto[C]String, renames them as nsAuto[C]StringN, and
redefines nsAuto[C]String as typedefs for nsAuto[C]StringN<64>.
(The alternative would be to templatize nsAuto[C]String and use a default
parameter, but that would require writing "nsAuto[C]String<>" everywhere.)
Kit Cambridge
Andrew Sutherland
Florian Quèze
Jared Wein
Andrew McCreight
Kris Maglione
Cosmin Sabou
Brindusan Cristian
Chris Peterson
Eric Rahm
Csoregi Natalia
Mark Banner
Gabriele Svelto
shindli
Nicholas Nethercote
Bob Owen
Sebastian Hengst
Kai Engert
Ryan VanderMeulen
Marco Bonardo
Jan de Mooij
Phil Ringnalda