We can use QM_TO_RESULT (instead of MOZ_TO_RESULT) because QM_WARNONLY_TRY
doesn't propagate errors, so no other adjustment is needed.
Differential Revision: https://phabricator.services.mozilla.com/D125314
We want to enforce the (assumed) invariant that after we started QM shutdown we should not create new contextes and associated threads for cache IO. We do this generating a runtime error, whose handling might not be consistent in all (unexpected) cases, yet. But this is preferable over a shutdown hang crash, for sure.
Differential Revision: https://phabricator.services.mozilla.com/D123137
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
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 eliminates the need for using andThen and orElse. This is now consistent
with hanling of STATE_ENSURE_ORIGIN_INITIALIZED.
Differential Revision: https://phabricator.services.mozilla.com/D115127
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
We have this issue because:
- We didn't check the returning nsresult after executing "VACUUM".
- The mismatch settings between upgrade code for the column request_integrity
and new table code for the column. (one is allowed to be NULL while the other
isn't)
- We rewrite the entries schema.
What we need to fix here are:
- The 21- schema databases. -> Fixing migration code from 21 to 22 should help.
- The 22+ schema databases. -> Requring a new upgrade code.
An alternative option is that maybe we can allow request_integrity to be NULL on
table entries.
Differential Revision: https://phabricator.services.mozilla.com/D107237
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
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D107355
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
The nesting level is tracked on the storage connection. The thread safety is
ensured by holding a lock while a transaction is being started/commited/rolled
back. For these purposes, the sharedDBMutex has been exposed on
mozIStorageConnection interface and additional helper methods have been added
to the interface as well.
Differential Revision: https://phabricator.services.mozilla.com/D106019
Existing uses of OriginMetadata (with only mGroup and mOrigin) have been
adapted and they now always initialize mSuffix to an empty string.
Following patches will change it to real suffix if there's any.
Differential Revision: https://phabricator.services.mozilla.com/D104971
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227