Create tor-browser for mobile branch based on mozilla-central

To prepare our first Tor Browser for Android alpha we need to create a separate branch in our tor-browser repo that is tracking the mozilla-central branch (rebased with our patches) we want to use in the release. Follow-up beta and stable branches are later on needed as well.

added TorBrowserTeam201806 component::applications/tor browser owner::sysrqb priority::very high resolution::wontfix severity::normal sponsor::8 status::closed tbb-mobile tbb-no-uplift type::defect labels

Repo: https://git.torproject.org/user/sysrqb/tor-browser.git Branch: bug25741_orfox_patches

Current status: The branch is actively being rebased, so don't expect stability. The branch does not include any tor-browser patches. Most Orfox patches are updated/rewritten. This branch does not include Orfox patches that rely on Orbot. From tor-browser-52.7.3esr-8.0-1-build2, the Orfox patches currently excluded from the above rebase-branch are:

c981d290167b8547789849194ed12dd763f1f892 - Orfox: Fix #1 - Improve build instructions
d17c8a5eddfc5b1241c65ff8cba9684f8ddc9237 - Orfox: NetCipher enabled, checks if orbot is installed
0642e45b991b25a0419dcb0e583320f10b17f0ed - Orfox: Centralized proxy applied to CrashReporter, SuggestClient, Distribution, AbstractCommunicator and BaseResources.
ee7554ab2fc836445fabe93ec0d9b256e5665ede - Orfox: add BroadcastReceiver to receive Tor status from Orbot
2a4853c5e267f7cfa75b771c65bf81232e66d14e - Orfox: queue URL Intents and Tab:Load events when Orbot is not yet started
9bc0b6bf3fc49d07c07dbd3755db5d2ac6da60d6 - Orfox: receive Tor status in thread so they arrive when event sync blocks
b5e9a36b9c333790fdea41e84c30d19b43aa58ac - Orfox: remove Tab:Load event queuing and only use Intent queuing
85b696c5a0e3c9e5d22c06fa179b512abcf22816 - Orfox: disable screenshots and prevent page from being in "recent apps"
acde62dc92325842ea70de678878f68117618448 - Orfox: hook up default panic trigger to "quit and clear"
f69137ac1edb29e3b193b2feeb6f581b7ba4170a - Orfox: Disabling search widget.
6e59d7eeb5ae4bf23dec2685d12bdd4f2b6e4df5 - Orfox: Adding GCM sender ID.
28bbaf1fdc792d2ff67b28769cff6bcdd2249a9d - Orfox: Update orfox branding and icon
f69137ac1edb29e3b193b2feeb6f581b7ba4170a - Orfox: Disabling search widget.
6e59d7eeb5ae4bf23dec2685d12bdd4f2b6e4df5 - Orfox: Adding GCM sender ID.
d5e91af5b5c6dc3812e9d85caed908e5ef07cc86 - Orfox: Strings fix, probably a WONTAPPLY ESR59.
a3270e7c8c07a62ee093f3b248fe9bab1e2e0619 - fix crash with registerReceiver for Orbot status
b88a0e4355a73561a542043c18eb1b2b7a617171 - addresses #9 to handle NPE on Distribution load
9bd1a8972351ca0ff3ff12c3661fd8dc10914ade - fixes #10 disables attempts to access AccountManager
61fc96d200948f725a77dacba9f8d0cac1142ef8 - handle #11 crash related to tor status receiver unregistering

We still must audit the code and confirm its proxy-safe. Some of the other patches are specifically for Orbot capability, and right now it seems unnecessary to introduce those patches and resolve rebasing conflict, if torlauncher is a dependency for the first alpha.

Trac:
Owner: tbb-team to sysrqb
Status: new to assigned

Okay, nearly done.

Notes: during the rebase I changed Orfox -> torbrowser, and I renamed .mozconfig-orfox -> .mozconfig-android.

While I updated .mozconfig-android:

1. I noticed BUILD_OFFICIAL is dead, I deleted this (maybe delete from other .mozconfig, too).
2. Question: why do we set MOZILLA_OFFICIAL in .mozconfig?
3. --disable-install-strip on mobile? What errors were seen before?

For (2), to be precise, from what I see mk_add_options MOZILLA_OFFICIAL=1 does not set MOZILLA_OFFICIAL=1. The in-tree mozconfigs use export MOZILLA_OFFICIAL=1 and they have a comment "# Needed to enable breakpad in application.ini" dated in 2011. I confirmed changing mk_add_options MOZILLA_OFFICIAL=1 to export MOZILLA_OFFICIAL=1 does set MOZILLA_OFFICIAL=1.

I'll research (3). The comment in .mozconfig-orfox says "== Known mobile build flag that causes errors", but I'd like having this documented so we know if/when this works.

I'm running a few more builds for testing (and then I'll wait for #25543 (moved))

Based on 61.0.a1 Repo: ​https://git.torproject.org/user/sysrqb/tor-browser.git Branch: bug25741_orfox_patches

Based on #25543 (moved) (60.0b15) + cherry-pick from bug25741_orfox_patches Repo: ​https://git.torproject.org/user/sysrqb/tor-browser.git Branch: bug25741_orfox_patches_beta_plus_25543+7

Testing a build from bug25741_orfox_patches_beta_plus_25543+7 confirms Necko connections do not bypass the proxy configured by pref. TBA should benefit from most of the proxy-bypass work done for desktop, so (as expected) we should concentrate on the java-based network connections.

Can we try to upstream these patches? I think all of them could benefit FF as well.

Bug 25741 - TBA: Conditionally require *_LOCATION permissions

Bug 25741 - TBA: Move GCM Push prefs within preprocessor guard

Bug 25741 - TBA: Only include GCM permissions if we want them

Bug 25741 - TBA: Only include Firefox Account permissions if we want them

Bug 25741 - TBA: Conditionally require *_WIFI_STATE permissions

Replying to igt0:

Can we try to upstream these patches?

Yes, I hope we upstream these (and a few others). Mozilla won't take these as-is, so we'll need to create proper patches for them. As an example, Orfox introduced MOZ_ACCOUNTS in the pre-processor preventing including FxAccounts but there's no way someone can enable it. Some of these patches re-use existing compile-time guards, so those should be easier to upstream. We should definitely uplift as many of these as possible.

Move our roadmap tickets to May.

Trac:
Keywords: TorBrowserTeam201804 deleted, TorBrowserTeam201805 added

Adjusting prios of some tickets.

Trac:
Priority: High to Very High

Trac:
Keywords: N/A deleted, tbb-mobile added

I guess we can use that (parent) bug to work on our general idea of automatically rebasing our patches against mozilla-central and figuring out what to do in case everything is okay/not okay. Should we run this rebase attempt daily? Weekly? Bi-weekly? I think I am against daily as a rebase failure might just be due to a broken m-c patch which is get fixed in $timeframe on mozilla-central "automatically" by Moz people. So, maybe starting with rebasing once a week could be a thing we try?

I guess having an automated system that sends notification email about the result of the rebase would be good, indicating on which git commit the rebase was on. In case everything is fine I can do the rebase locally and push the result to our nightly branch.

If it is not okay, we should file a ticket I guess with a special keyword and then someone from the team (maybe we create a particular role for that that is assigned on a weekly basis, like "rebase-hero") is looking into that and fixing up the issues. The idea would be to have things ready for review and merged until the next rebase attempt is running.

If things are more thoroughly broken we can decide on a case-by-case basis what to do but fixing those problems will always be a top prio because we need enough testing time with functional builds to get the next Tor Browser for Android into stable shape.

Trac:
Cc: sysrqb, igt0 to sysrqb, igt0, boklm

Moving our tickets to June 2018

Trac:
Keywords: TorBrowserTeam201805 deleted, TorBrowserTeam201806 added

We'll base TBA on ESR60 instead of follow -release and/or -central. See #26401 (moved). Once we start to do the automatic rebasing of our patches (which is still a good idea) we should open a new bug tracking all the problems we hit.

Trac:
Status: assigned to closed
Resolution: N/A to wontfix

Sponsor8 in June 2018.

Trac:
Sponsor: N/A to Sponsor8

Trac:
Keywords: N/A deleted, tbb-no-uplift added

closed

mentioned in issue #26233 (moved)

mentioned in issue #34372 (moved)

moved to tpo/applications/tor-browser#25741 (closed)

mentioned in issue tpo/applications/tor-browser#34372 (closed)