Closed Bug 668542 Opened 11 years ago Closed 11 years ago

Cancelling MP unlock will trigger an error and point user to Sync Preferences dialog window


(Firefox :: Sync, defect)

Not set





(Reporter: tchung, Assigned: philikon)



(Whiteboard: [fixed in services])


(1 file)

The use case doesnt make sense here.  If i cancel out of unlocking a Master Password dialog, and then try to force sync, the yellow sync bar appears with a Preferences button, and takes me to the Sync Prefs window.   There's nothing in the sync prefs window indicating to the user what to do next.

1) install 6/30/2011 trunk nightly on S-c: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110627 Firefox/7.0a1
2) enable master password
3) force a sync
4) master password unlock dialog appears.   Cancel out of it
5) Sync throws a yellow bar error with a Preferences button. Log shown is:

1309451037342	Sync.Service	DEBUG	Exception: Login failed: service.master_password_locked No traceback available
1309451037342	Sync.Service	DEBUG	Not syncing: login returned false.
1309451077293	Sync.Service	INFO	Starting sync at 2011-06-30 09:24:37
1309451077294	Sync.Service	DEBUG	In sync: should login.
1309451077295	Sync.Service	INFO	Logging in user iscgg6sijlrazamiygizww4ta2t54mfx
1309451079420	Sync.Service	DEBUG	Fetching passphrase threw [Exception... "User canceled master password entry"  nsresult: "0x80004004 (NS_ERROR_ABORT)"  location: "JS frame :: resource:///components/crypto-SDR.js :: <TOP_LEVEL> :: line 203"  data: no]; assuming master password locked.
1309451079434	Sync.SyncScheduler	DEBUG	Clearing sync triggers.
1309451079435	Sync.SyncScheduler	DEBUG	Couldn't log in: master password is locked.
1309451079435	Sync.SyncScheduler	CONFIG	Starting backoff, next sync at:Thu Jun 30 2011 09:39:39 GMT-0700 (PDT)

6) Verify clicking Prefs button in the yellow error bar takes user to The Sync Prefs window

- take the user to unlocking the master password prefs instead (prefs > privacy)

- takes user to sync prefs window, where there is no instruction on what to do next.
Regression from bug 664792 part 2. I know what's wrong, working on a patch.
Assignee: nobody → philipp
Blocks: 664792
Attached patch v1Splinter Review
Previously Service.login() special-cased MASTER_PASSWORD_LOCKED and didn't notify weave:service:login:error. Bug 664792 part 2 got rid of that because we *want* it to notify login error. We forgot that this would also trigger an error bar, however.

Fortunately, there's a hook that the UI calls before deciding to show an error: Weave.Service.shouldIgnoreError(). So this amends that function to ignore MASTER_PASSWORD_LOCKED, thereby getting us back to the same UI behaviour.

(All of our error handling code makes me sad. It's time we ripped this out of Service, the UI, and various other places, and created a centralized policy object.)
Attachment #543162 - Flags: review?(rnewman)
(In reply to comment #2)

> (All of our error handling code makes me sad. It's time we ripped this out
> of Service, the UI, and various other places, and created a centralized
> policy object.)

Long overdue!
OS: Mac OS X → All
Hardware: x86 → All
Attachment #543162 - Flags: review?(rnewman) → review+
Whiteboard: [fixed in services]
Closed: 11 years ago
Resolution: --- → FIXED
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.