Bug 1787619 Comment 25 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

It would be great if you could pick that up.

I'm quite uncertain on the semantics we should expose here though - even if we look past the fact that `accountCanSync` something like `accountCanSync` accurately reflects what we did with SyncedTabs - ie, that `Weave.Status.login != Weave.STATUS_OK`. But from the point of view of the UI, that *does not* necessarily imply that the actual status is `MASTER_PASSWORD_LOCKED` - it almost certainly is if `UIState.get() == UIState.STATUS_SIGNED_IN`, but that's not certain.

From the POV of the UI, I assume that you will also want to offer some way to unlock - but I don't think it makes sense for UIState to offer that. So instead of UIState exposing a proxy for "is the primary password unlocked", it seems like getting the info from the source of truth is better - ie, ignore sync itself here and just use the password manager itself - ask it if the primary password is locked (sync will not work if it is) and ask it to unlock if when the user requests via whatever UI affordance you come up with.

https://searchfox.org/mozilla-central/source/toolkit/components/passwordmgr/LoginHelper.jsm seems to offer an unlock function - it doesn't seem to offer a simple "is locked" function, but you could just copy how sync does it [here](https://searchfox.org/mozilla-central/source/services/sync/modules/util.js#638)
It would be great if you could pick that up.

I'm quite uncertain on the semantics we should expose here though - even if we look past the fact that `accountCanSync` is a bad name, it would accurately reflect what we did with SyncedTabs - ie, that `Weave.Status.login != Weave.STATUS_OK`. But from the point of view of the UI, that *does not* necessarily imply that the actual status is `MASTER_PASSWORD_LOCKED` - it almost certainly is if `UIState.get() == UIState.STATUS_SIGNED_IN`, but that's not certain.

From the POV of the UI, I assume that you will also want to offer some way to unlock - but I don't think it makes sense for UIState to offer that. So instead of UIState exposing a proxy for "is the primary password unlocked", it seems like getting the info from the source of truth is better - ie, ignore sync itself here and just use the password manager itself - ask it if the primary password is locked (sync will not work if it is) and ask it to unlock if when the user requests via whatever UI affordance you come up with.

https://searchfox.org/mozilla-central/source/toolkit/components/passwordmgr/LoginHelper.jsm seems to offer an unlock function - it doesn't seem to offer a simple "is locked" function, but you could just copy how sync does it [here](https://searchfox.org/mozilla-central/source/services/sync/modules/util.js#638)

Back to Bug 1787619 Comment 25