Closed
Bug 559372
Opened 13 years ago
Closed 13 years ago
Fennec start page still shows weave tabs option after logging out of Weave
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(fennec2.0b1+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0b1+ | --- |
People
(Reporter: tchung, Assigned: vingtetun)
References
Details
(Whiteboard: [fennec-checkin-posta1])
Attachments
(1 file, 1 obsolete file)
12.46 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
When you sync weave with fennec, the start page updates to include displaying tabs from other computers. however, if you sign out of weave, the start page does not update correctly to remove that entry. The weave sync icon does gray out as i would expect it to. See screenshot Repro: 1) install fennec 1.1pre build 20100414 2) install weave 1.2 3) connect to a weave account and sync tabs 4) visit start page and notice fennec start page has an entry for "tabs from my other computers" 5) now log out of weave 6) restart 7) Verify after reopening, the weave sync icon in the left sidebar is grayed out, but the fennec start page still displays the entry of tabs from my other computers" Expected: - Fennec start page should not show any instance of tabs for weave if signed out. Actual: - fennec start page still shows the remainder of the Tabs from my other computers entry
Reporter | ||
Comment 1•13 years ago
|
||
Reporter | ||
Comment 2•13 years ago
|
||
similar to bug 558923. resetting blocking-fennec flag.
tracking-fennec: 1.1+ → ?
Comment 3•13 years ago
|
||
This is still true in Fennec 2.0a1pre with built-in Firefox Sync. Also, "Desktop Bookmarks" still appears and contains data after signing out of Sync.
Assignee: nobody → mbrubeck
OS: Linux → All
Hardware: ARM → All
Updated•13 years ago
|
tracking-fennec: ? → 2.0b1+
Updated•13 years ago
|
Assignee: mbrubeck → 21
Assignee | ||
Comment 4•13 years ago
|
||
This does not resolve the bookmarks case but handle the start page case by enabling/disabled the row on the start page since weave is now built in (instead of hiding it) The patch also handle the case where MOZ_SERVICES_SYNC is not defined
Attachment #439026 -
Attachment is obsolete: true
Attachment #468340 -
Flags: review?(mark.finkle)
Comment 5•13 years ago
|
||
(In reply to comment #3) > Also, "Desktop Bookmarks" still appears and contains data after signing out of > Sync. As it should. The bookmarks _are_ in Fennec now, so we don't need a live Sync connection to use them.
Comment 6•13 years ago
|
||
Comment on attachment 468340 [details] [diff] [review] Patch >+ function updateWeaveButton() { >+ let isDisabled = !getChromeWin().Weave.Service.isLoggedIn; >+ document.getElementById("remoteTabs").setAttribute("disabled", isDisabled); I think we should removeAttribute if isDisabled == false I also wonder if we should just remove the remote tabs widget from the startup page, but that's a separate issue.
Attachment #468340 -
Flags: review?(mark.finkle) → review+
Updated•13 years ago
|
Whiteboard: [fenn
Updated•13 years ago
|
Whiteboard: [fenn → [fennec
Updated•13 years ago
|
Whiteboard: [fennec → [fennec-checkin-posta1]
Comment 7•13 years ago
|
||
Do we really want this disabled on startup? If it's enabled on startup, you can see your already-synced remote tabs right away, which seems useful even if they are not as up-to-date as possible. We can disable the UI on logout, or if there is no username/password configured on startup.
Comment 8•13 years ago
|
||
(In reply to comment #7) > Do we really want this disabled on startup? If it's enabled on startup, you > can see your already-synced remote tabs right away, which seems useful even if > they are not as up-to-date as possible. We can disable the UI on logout, or if > there is no username/password configured on startup. I suppose we could be smarter if we know that Sync data exists locally.
Comment 9•13 years ago
|
||
(In reply to comment #8) > (In reply to comment #7) > > Do we really want this disabled on startup? If it's enabled on startup, you > > can see your already-synced remote tabs right away, which seems useful even if > > they are not as up-to-date as possible. We can disable the UI on logout, or if > > there is no username/password configured on startup. > > I suppose we could be smarter if we know that Sync data exists locally. The same is true for the new Awesomescreen. Instead of disabling the remote tabs button, we could do something smarter and look for local Sync data. Followup bug?
Assignee | ||
Comment 10•13 years ago
|
||
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Do we really want this disabled on startup? If it's enabled on startup, you > > > can see your already-synced remote tabs right away, which seems useful even if > > > they are not as up-to-date as possible. We can disable the UI on logout, or if > > > there is no username/password configured on startup. > > > > I suppose we could be smarter if we know that Sync data exists locally. > > The same is true for the new Awesomescreen. Instead of disabling the remote > tabs button, we could do something smarter and look for local Sync data. > > Followup bug? http://hg.mozilla.org/mobile-browser/rev/1e4330671841 I've opened bug 590067 for that but I'm pretty sure we will need Madhava to decide what to show if there is no old data but the user go to the remote tabs panel: a quick explanation of how to configure weave and a link to redirect to the preference pane?
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 11•13 years ago
|
||
verified FIXED on builds: Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:2.0b5pre) Gecko/20100825 Namoroka/4.0b5pre Fennec/2.0a1pre and Mozilla/5.0 (Android; Linux armv71; Nokia N900; en-US; rv:2.0b5pre) Gecko/20100825 Namoroka/4.0b5pre Fennec/2.0a1pre
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Reporter | ||
Comment 12•13 years ago
|
||
Assigning to self to create a litmus testcase.
Assignee: 21 → tchung
Comment 13•13 years ago
|
||
(In reply to comment #12) > Assigning to self to create a litmus testcase. The assignee field is only for the developer who wrote the patch.
Assignee: tchung → 21
Comment 14•13 years ago
|
||
We talked about this on irc with blassey and ted. We're experimenting.
Reporter | ||
Comment 15•13 years ago
|
||
having the email address in in-litmus should work.
Flags: in-litmus? → in-litmus?(tchung)
Reporter | ||
Comment 16•13 years ago
|
||
Added litmus test: https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=12934
Flags: in-litmus?(tchung) → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•