NS_LogCOMPtrAddRef and NS_LogCOMPtrRelease always pass false to
GetSerialNumber, because they pass in everything they get without
regard to whether it is being logged or not, so they don't want to
create a serial number if none exists. This causes the assertions
added in bug 1309051 to be hit. To work around this, I hoist the
assertion into the other callers of this method. Two of them already
had this check, but it was non-fatal.
This also makes the asserts not happen in release builds, as I decided
it doesn't really matter what happens if somebody tries to use it
there.
--HG--
extra : rebase_source : 5e70290492fd442b79b4d40c300a263e322f485b
With the added safety checks it's unlikely that anything in this function will
fire ObjC exceptions, but our rule is to have guards around every Objective C
function that can directly be called from C++ files.
MozReview-Commit-ID: GQ0bN5638Sf
--HG--
extra : rebase_source : 3919f4a2b8160f197e1690ba13b58319239848e1
extra : source : 3d233eddd929e0cb2cadf0b07f75d60aa3fba419
This potentially changes behavior. On my machine, the old code returned
NS_ERROR_FAILURE because the dictionary did not have a "countryCode" entry,
but this new implementation correctly returns the string "CA".
MozReview-Commit-ID: 17Vme0fcAIw
--HG--
extra : rebase_source : 9ffc388ae98b11cb37c37957a8721e92284208c3
extra : source : e1a14b0c638571ec7f7aaec56f11d4b77dfb4dd5
NS_FOUND_TARGET is now declared as an error code. However, making it as a success code makes the code simpler.
First, this patch renames it to NS_SUCCESS_EDITOR_FOUND_TARGET because it's usual naming rule (according to the other declarations).
Next, FindTargetNode() should return it when a nest call of itself returns NS_SUCCESS_EDITOR_FOUND_TARGET as it does now.
Finally, removing the code overwriting NS_FOUND_TARGET with NS_OK from HTMLEditor::CreateDOMFragmentFromPaste() since it doesn't cause hitting NS_ENSURE_SUCCESS() and the variable, rv, will be overwritten with other method's result.
MozReview-Commit-ID: 6GgZptrXXQa
--HG--
extra : rebase_source : 79418fc83fb087e559221f895c59c7c334980456
This is an unrelated change to fix an issue that was bothering me.
MozReview-Commit-ID: Cxw9WhHfSAf
--HG--
extra : rebase_source : 10e3b3f28ecad0af216dbb368ffdb3b0ff75c7f9
Nobody asks for the new stats, only the total ones, so there's no need
for two sets of statistics.
MozReview-Commit-ID: AO0ue9MPn3N
--HG--
extra : rebase_source : 8d5237c4efdc0ece5bf1a386cae38e394aaadf01
Only about:bloat used NEW_STATS, so act like we have ALL_STATS
everywhere. A later patch will remove the mNewStats field.
MozReview-Commit-ID: LUJBpS3iYht
--HG--
extra : rebase_source : 543951314e12e7964e3f25c155b658d50ce674a6
DumpStatistics does not track any objects that are created or
destroyed while it is running, which means that any subsequent calls
to it will produce incorrect results. This can lead to incorrect
positive or negative leaks being reported. See 1271182.
Now that about:bloat has been removed, DumpStatistics should only be
called once, during shutdown.
MozReview-Commit-ID: IjMkExeBRBr
--HG--
extra : rebase_source : 5966789c2febfedc796d17f8589e8c3703d266cb
* Only allows setting the log file at runtime if not set by an Env Var
* LogModulePrefWatcher will watch logging.config. prefs and call into Logging.cpp to set the log file, sync or timestamp
* Log files set by pref will have a -main.PID or -child.PID suffix
* If the logging.config.clear_on_startup pref is true, prefs will be reset upon restart.
MozReview-Commit-ID: CWJujX4jm2A
