Bugzilla

(In reply to Simon Giesecke [:sg] [he/him] from comment #40)
> > We currently use nsIPrincipal and MozURL to get the origin string. PrincipalVerifier exists to catch any inconsistencies between those two
> Is that the sole purpose of PrincipalVerifier? In that case, it seems a quite odd place to perform this check.

Where would you do it instead ?
nsIPrincipal can't be used off main thread and we can't create a helper that would synchronously block a current thread while we want for processing on the main thread (that would lead to deadlocks because LSNG is synchronous API).

> > So yes, the flipping of the pref on the fly is unfortunate and we need to do something with it. I'm not sure if we do a snapshot of the setting and just use that during entire session. It needs to be investigated.
> Ah, so this only happens when the pref is flipped during a session? I thought it might be happening because it was flipped between the time some QM-managed storage was created and it is accessed, which might be across sessions. If it only happens when the pref is flipped during a session, then the solution might be to trigger re-initialization of all QM clients in that case (or even further re-initialization).

That sounds like a lot of work and I'm not sure how would that look like, what about existing operations ?

I think we need something simpler.

(In reply to Simon Giesecke [:sg] [he/him] from comment #40)
> > We currently use nsIPrincipal and MozURL to get the origin string. PrincipalVerifier exists to catch any inconsistencies between those two
> Is that the sole purpose of PrincipalVerifier? In that case, it seems a quite odd place to perform this check.

Where would you do it instead ?
nsIPrincipal can't be used off main thread and we can't create a helper that would synchronously block a current thread while we wait for processing on the main thread (that would lead to deadlocks because LSNG is synchronous API).

> > So yes, the flipping of the pref on the fly is unfortunate and we need to do something with it. I'm not sure if we do a snapshot of the setting and just use that during entire session. It needs to be investigated.
> Ah, so this only happens when the pref is flipped during a session? I thought it might be happening because it was flipped between the time some QM-managed storage was created and it is accessed, which might be across sessions. If it only happens when the pref is flipped during a session, then the solution might be to trigger re-initialization of all QM clients in that case (or even further re-initialization).

That sounds like a lot of work and I'm not sure how would that look like, what about existing operations ?

I think we need something simpler.