Closed Bug 543851 Opened 15 years ago Closed 15 years ago

autoconnect should call _checkSync()

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dholbert, Assigned: mconnor)

Details

Attachments

(2 files)

STEPS TO REPRODUCE: 1. Install Weave, & set it up with a weave account. 2. In the Firefox Preferences "Privacy" pane, choose "Use my custom settings for history" in the dropdown at the top, and check "Permanent Private Browsing Mode" 3. Restart Firefox, and watch Weave status bar icon in new session. ACTUAL RESULTS: - When Firefox restarts, it shows "Disabled (Private Browsing)" in the weave status-bar for a few seconds. If I click Weave menu, "Connect" and "Sync Now" are there but grayed out. - Then the Weave statusbar icon starts spinning, and "Disabled (Private Browsing)" is replaced with my username - Then it changes to just show my username & the weave icon, like I'm normally logged in. Now, "Disconnect" and "Sync Now" are in the Weave menu, though grayed out. INTERPRETATION OF ACTUAL RESULTS: - Weave is logging in - Weave is not syncing anything (or at least not letting me manually sync) since it's in private browsing mode - Weave is not telling the user that it's in private browsing mode (so it's confusing why things aren't syncing) EXPECTED RESULTS: - Weave should just stay as "Disabled (Private Browsing)" - Weave probably shouldn't be autoconnecting when it's in private browsing mode.
Summary: Weave loses the visible "Disabled (Private Browsing)" status, a few seconds after I start Firefox in Permanent Private Browsing Mode → Weave autoconnects & loses the visible "Disabled (Private Browsing)" status, a few seconds after I start Firefox in Permanent Private Browsing Mode
Version info: Weave Sync 1.0 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre
Attached file verbose log
Here's the verbose log, starting from Step 3 in the steps to reproduce (Firefox starting up in "permanent private browsing mode" with weave already configured) It indicates that Weave is indeed logging me in, despite me being in private browsing mode.
ALTERNATE STEPS TO REPRODUCE, without permanent private browsing: 1. Set up Weave, etc. 2. Restart Firefox. 3. When Firefox starts, immediately (before Weave autoconnects) start Private Browsing mode (Ctrl+Shift+P) and click through the "are you sure?" dialog ACTUAL RESULTS: Same as in comment 0 -- weave status bar briefly changes to "Disabled (Private Browsing)", and then changes to my Weave username, indicating that it's just logged me in.
Summary: Weave autoconnects & loses the visible "Disabled (Private Browsing)" status, a few seconds after I start Firefox in Permanent Private Browsing Mode → Weave autoconnect can be triggered during Private Browsing mode & remove the "Disabled (Private Browsing)" status
Summary: Weave autoconnect can be triggered during Private Browsing mode & remove the "Disabled (Private Browsing)" status → autoconnect needs to check most of what's in _checkSync()
Target Milestone: --- → 1.3
Test is "start Firefox with -private, verify we don't do anything"
Component: Firefox UI → Sync
Flags: blocking-weave1.3+
QA Contact: firefox → sync
Assignee: nobody → mconnor
Summary: autoconnect needs to check most of what's in _checkSync() → autoconnect should call _checkSync()
Attached patch v1Splinter Review
* add an ignore param to checkSync for reasons that shouldn't be returned * call _checkSync in _autoConnect ignoring not logged in and firstSyncChoiceNotMade (being added in bug 551572) * fix the caller in _checkSyncStatus to use the new arg instead of checking retval
Attachment #437758 - Flags: review?(edilee)
Whiteboard: [has patch][needs review Mardak]
Comment on attachment 437758 [details] [diff] [review] v1 >+++ b/source/modules/service.js >+ let reason = >+ Utils.mpLocked() ? "master password still locked" >+ : this._checkSync([kSyncNotLoggedIn, Might be interesting to think about if the master password check should be part of checkSync. Issue is that master password might get relocked after (?) but we've cached the passwords, so no need to worry about mpLocked at that point.
Attachment #437758 - Flags: review?(edilee) → review+
Whiteboard: [has patch][needs review Mardak] → [has patch][has review]
mplocked only matters for the autoconnect case. In all other cases, it's irrelevant, so it'd just complicate things.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review]
Target Milestone: 1.3 → 1.3b1
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: