This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
The reason this was originally added was for bug 1516277 in order to allow a
synchronous dispatch to a background thread to create a new PBackground
instance without deadlocking. The dispatch didn't want to support running other
main thread runnables, but needed to support sending the runnable to create a
new PBackground instance on the main thread.
This is no longer an issue since bug 1737828, where we changed PBackground
startup to no longer require the main thread, so we can remove the complexity
and instead use a monitor to handle changes. This also allows removing the
timer, as the monitor's timeout can be used instead.
I also changed the logic slightly to make it more likely to catch an expecting
shutdown by waiting on the monitor with a timeout, as previously the main
thread would not be being woken up and checking the condition very often, due
to it not having any runnables to execute.
Differential Revision: https://phabricator.services.mozilla.com/D164840
The reason this was originally added was for bug 1516277 in order to allow a
synchronous dispatch to a background thread to create a new PBackground
instance without deadlocking. The dispatch didn't want to support running other
main thread runnables, but needed to support sending the runnable to create a
new PBackground instance on the main thread.
This is no longer an issue since bug 1737828, where we changed PBackground
startup to no longer require the main thread, so we can remove the complexity
and instead use a monitor to handle changes. This also allows removing the
timer, as the monitor's timeout can be used instead.
I also changed the logic slightly to make it more likely to catch an expecting
shutdown by waiting on the monitor with a timeout, as previously the main
thread would not be being woken up and checking the condition very often, due
to it not having any runnables to execute.
Differential Revision: https://phabricator.services.mozilla.com/D164840
We don't abort the event loop spinning before the request is actually finished
because that would cause races between the current thread and DOM File thread.
Instead, we send the cancel message to the parent and wait for the request to
finish like in the normal case when the request is successfully finished on
time. OnResponse is called as the final step in both cases.
Differential Revision: https://phabricator.services.mozilla.com/D146058
This patch avoids requiring the main thread to create PBackground instances by
instead using a background starter TaskQueue, and sending messages from a
PBackgroundStarter actor hosted on that thread to the target background thread
directly. On the background thread, the relevant metadata is already registered
and present in the BackgroundStarterParent actor allowing the main thread in
both processes to be bypassed completely.
Various tasks remain bound to the main thread, such as PBackground cleanup and
async steps involved in PBackground creation.
This patch also unifies the in-process and cross-process PBackground codepaths,
allowing in-process PBackground creation to bypass the main thread as well, and
removing the need for a main thread event target from
GetOrCreateForCurrentThread().
Differential Revision: https://phabricator.services.mozilla.com/D129705
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
Currently, we use the script principal to verify the client to prevent
the principal forgery. After we moving to use foreign partitioned
principal for the Client, this no longer works. Instead, we can directly
use the client's principal to verify client.
Also, the patch rename StoragePrincipalHelper::VerifyValidStoragePrincipalInfoForPrincipalInfo() to
StoragePrincipalHelper::VerifyValidPartitionedPrincipalInfoForPrincipalInfo()
and fix a problem in the function that it should ignore the PartitionKey
instead of the FirstPartyDomain.
Differential Revision: https://phabricator.services.mozilla.com/D127840
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
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
This also changes all methods that use a pair of group/origin or a tuple of
suffix/group/origin input/output parameters to use a single GroupAndOrigin
resp. QuotaInfo struct input parameter or return value. Also, several types
having a pair or 3-tuple of such data members are changed to use these structs
instead.
Differential Revision: https://phabricator.services.mozilla.com/D91131
