Opened 18 months ago

Closed 6 months ago

#22564 closed defect (duplicate)

Hide firefox sync

Reported by: Dbryrtfbcbhgf Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-7.0-issues, tbb-regression, ff60-esr, TorBrowserTeam201805
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor browser bundle has filefox sync under the menu button and then click sync'ed tabs. and it should be removed to protect users form accidentally enabling it and revealing there search history.

Child Tickets

Attachments (1)

issue.png (49.1 KB) - added by Dbryrtfbcbhgf 18 months ago.

Download all attachments as: .zip

Change History (17)

Changed 18 months ago by Dbryrtfbcbhgf

Attachment: issue.png added

comment:1 Changed 18 months ago by Dbryrtfbcbhgf

Priority: MediumHigh

comment:2 Changed 18 months ago by gk

Keywords: tbb-7.0-issues tbb-regression added
Priority: HighMedium
Summary: Remove firefox syncHide firefox sync

Let's not remove it but hide it. We had/have code that did/does that in our esr45 branches. I guess we need to update it properly for esr52.

comment:3 Changed 15 months ago by arthuredelstein

Keywords: TorBrowserTeam201709R added
Status: newneeds_review

Here's a branch with two patches for review. The first patch is a fixup that the hides Sync UI elements. The second patch is a regression test.

https://github.com/arthuredelstein/tor-browser/commits/22564

And here's a torbutton patch for review, that removes some Sync UI hiding code that has been moved into the tor-browser fixup patch.

https://github.com/arthuredelstein/torbutton/commit/22564

comment:4 Changed 14 months ago by gk

Keywords: TorBrowserTeam201709 added; TorBrowserTeam201709R removed
Status: needs_reviewneeds_revision

I tested it on a Linux system and it works for me, thanks. One thing to fix:

+      Services.prefs.removeObserver(PREF_SYNC_UI_HIDDEN, gSyncUI, false);

I don't think there is a removeObserver() that takes three arguments.

Then you are adding observers in two more places (preferences.js and CustomizableUI.jsm) without removing them. I wonder whether that was intentionally. If so, shouldn't we remove them e.g. when the preferences pane is closed given that we are adding it when opening that very pane.

comment:5 Changed 14 months ago by gk

Keywords: TorBrowserTeam201710 added; TorBrowserTeam201709 removed

Items for October 2017

comment:6 Changed 13 months ago by gk

Keywords: TorBrowserTeam201711 added; TorBrowserTeam201710 removed

Moving tickets over to November.

comment:7 Changed 12 months ago by gk

Moving tickets to December 2017

comment:8 Changed 12 months ago by gk

Keywords: TorBrowserTeam201712 added; TorBrowserTeam201711 removed

Moving tickets to December 2017, for realz.

comment:9 Changed 10 months ago by gk

Keywords: TorBrowserTeam201801 added; TorBrowserTeam201712 removed

Moving tickets to 2018.

comment:10 Changed 10 months ago by gk

Keywords: TorBrowserTeam201802 added; TorBrowserTeam201801 removed

Moving tickets to Feb

comment:12 Changed 9 months ago by gk

Keywords: TorBrowserTeam201803 added; TorBrowserTeam201802 removed

Adding to our March plate.

comment:13 Changed 8 months ago by Dbryrtfbcbhgf

Replying to gk:

Adding to our March plate.

gk, it looks like Mozilla fixed this bug in Firefox 60 with this patch.
https://hg.mozilla.org/mozilla-central/rev/109cd0a34ffe
Can this be back ported to TorBrowser 7.5.x ?

Last edited 8 months ago by Dbryrtfbcbhgf (previous) (diff)

comment:14 Changed 8 months ago by gk

Keywords: TorBrowserTeam201804 ff60-esr added; TorBrowserTeam201803 removed

Hm. The patch is rather largish and probably won't apply cleanly. I am not sure, we might try it at least. If it does not work out we should flip the proper pref when we are switching to ESR 60, though.

comment:15 Changed 7 months ago by gk

Keywords: TorBrowserTeam201805 added; TorBrowserTeam201804 removed

Moving remaining tickets to May.

comment:16 in reply to:  14 Changed 6 months ago by gk

Resolution: duplicate
Status: needs_revisionclosed

Replying to gk:

Hm. The patch is rather largish and probably won't apply cleanly. I am not sure, we might try it at least. If it does not work out we should flip the proper pref when we are switching to ESR 60, though.

That's done with the rebasing in #25543. Thus, marking this as a duplicate.

Note: See TracTickets for help on using tickets.