Closed
Bug 543851
Opened 15 years ago
Closed 15 years ago
autoconnect should call _checkSync()
Categories
(Firefox :: Sync, defect)
Firefox
Sync
Tracking
()
RESOLVED
FIXED
1.3b1
People
(Reporter: dholbert, Assigned: mconnor)
Details
Attachments
(2 files)
1.29 KB,
text/plain
|
Details | |
2.12 KB,
patch
|
Mardak
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•15 years ago
|
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
Reporter | ||
Comment 1•15 years ago
|
||
Version info:
Weave Sync 1.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre
Reporter | ||
Comment 2•15 years ago
|
||
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.
Reporter | ||
Comment 3•15 years ago
|
||
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.
Reporter | ||
Updated•15 years ago
|
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
Assignee | ||
Updated•15 years ago
|
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
Assignee | ||
Comment 4•15 years ago
|
||
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 | ||
Updated•15 years ago
|
Assignee: nobody → mconnor
Assignee | ||
Updated•15 years ago
|
Summary: autoconnect needs to check most of what's in _checkSync() → autoconnect should call _checkSync()
Assignee | ||
Comment 5•15 years ago
|
||
* 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)
Assignee | ||
Updated•15 years ago
|
Whiteboard: [has patch][needs review Mardak]
Comment 6•15 years ago
|
||
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+
Updated•15 years ago
|
Whiteboard: [has patch][needs review Mardak] → [has patch][has review]
Assignee | ||
Comment 7•15 years ago
|
||
mplocked only matters for the autoconnect case. In all other cases, it's irrelevant, so it'd just complicate things.
Assignee | ||
Comment 8•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review]
Assignee | ||
Updated•15 years ago
|
Target Milestone: 1.3 → 1.3b1
Updated•6 years ago
|
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.
Description
•