ExecuteInitialization now takes a function argument instead of nsresult so
initializations are executed in the context of ExecuteInitialization. This
patch also removes a temporary overload of ExecuteInitialization.
Differential Revision: https://phabricator.services.mozilla.com/D119263
ExecuteInitialization now takes a function argument instead of nsresult so
initializations are executed in the context of ExecuteInitialization. This
patch also removes a temporary overload of ExecuteInitialization.
Differential Revision: https://phabricator.services.mozilla.com/D119263
There are some few unsafe uses of MaybeRecordShutdownStep where the QuotaManager singleton may be not (yet or anymore) alive.
In order to not add many unnecessary null checks, we drop GetRef and MaybeRecordShutdownStep in favor of
QuotaManager::MaybeRecordQuotaClientShutdownStep
QuotaManager::SafeMaybeRecordQuotaClientShutdownStep
with the sole difference that the Safe variant runtime checks the singleton, while the normal one only asserts.
Differential Revision: https://phabricator.services.mozilla.com/D115988
This is more consistent with other cases where we either use QM_OR_ELSE_WARN or
QM_OR_ELSE_NOTE. We will later change some uses of QM_OR_ELSE_LOG to
QM_OR_ELSE_LOG_IF. The switch from custom OrElseIf to Result::orElseIf will be
easier when we don't use OrElseIf directly.
This patch only changes uses of ordinary orElse introduced in bug 1701346.
Remaining uses will be handled in bug 1711180 (the ones that were missed in bug
1686191).
Differential Revision: https://phabricator.services.mozilla.com/D115055
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
The module argument in LogError is redundant: the module information can
already be determined from the source file path. Indeed, reporting the module
separately in the telemetry events seems unnecessary. Instead, the relative
path is now reported. This is what the analysis of the telemetry data did
reconstruct anyway.
As a consequence, it's no longer necessary to define module-specific
HandleError functions, and therefore it's also unnecessary to define
module-specific TRY macros. These are retained as simple aliases for now,
but can be removed in a later patch entirely.
This also avoids misuses of a TRY macros in the wrong module, which were
happening a few times before, resulting in confusing output or telemetry
events.
Since Bug 1686191 will add some more TRY macro variants that warn, so
simplifying the module-specific aspects will simplify that task. Furthermore,
this is in preparation of moving the TRY macro extensions to MFBT.
Differential Revision: https://phabricator.services.mozilla.com/D102767
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
The existing members of OriginMetadata have been extracted to a parent struct
called PrincipalMetadata. Methods like GetOriginUsage,
GetInfoFromValidatedPrincipalInfo, GetInfoFromPrincipal and GetInfoForChrome
have been changed to take/return PrincipalMetadata instead of OriginMetadata.
Having the persistence type doesn't make sense in those methods because the
origin is not tied to a specific persistence type in context of the methods.
Some places temporarily pass PERSISTENCE_TYPE_INVALID and will be fixed in
following patches.
Differential Revision: https://phabricator.services.mozilla.com/D106400
The new method is mandatory because mozStorageTransaction constructor no longer
starts the transaction. It must be started explicitely.
All consumers have been adjusted, but only dom/quota, dom/indexedDB, dom/cache,
dom/localstorage and dom/storage handle the error. Other components like
netwerk/cache, netwerk/cookie and toolkit/components currently only warn on
failure to start a transaction. Bug 1696129, 1696130 and 1696133 have been
filed for proper handling of transaction start failures in those components.
Differential Revision: https://phabricator.services.mozilla.com/D106893
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Gabriele Svelto
Jan Varga
Sandor Molnar
Jens Stutte
Tom Tung
Simon Giesecke
Butkovits Atila
Alexandru Michis