[tor-bugs] #33184 [Applications/Tor Browser]: Support for Fenix

[Tor Bug Tracker & Wiki]

#33184: Support for Fenix
--------------------------------------+--------------------------------
 Reporter:  sisbell                   |          Owner:  tbb-team
     Type:  enhancement               |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-mobile, Android       |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:  Sponsor58-must
--------------------------------------+--------------------------------

Comment (by acat):

 Replying to [comment:13 gk]:
 > a) our patches rebased regularly onto `mozilla-beta` for the `geckoview`
 part (1 branch for `geckoview` to track)
 > b) patches rebased regularly onto `master` and `releases/$VERSION` (for
 `38.0` there is no release branch (yet) thus we need to create one based
 on the latest tag instead) for `android-components` (about 2 branches for
 `android-components` to track)
 > c) patches rebased regularly onto `master` and `releases/$VERSION` for
 `fenix` (2 branches for `fenix` to track).
 I think this makes sense, having just the minimum number of branches
 needed for now.

 Just to make sure we're on the same page. I assume that from `android-
 components`, we only care about `geckoview_beta`, the version of which is
 set in `Gecko.kt` with `beta_version`. And, in case we have to patch
 `components/browser/engine-gecko-*`, we will only patch
 `components/browser/engine-gecko-beta` and not `components/browser/engine-
 gecko-nightly` or `components/browser/engine-gecko`, right?

 I understand that `geckoview_beta` will always point to a geckoview build
 which is based on some commit of the `mozilla-beta` branch. So, whenever
 some `android-components` branch that we track bumps `geckoview_beta`
 (e.g. every 2-3 days), are we going to create a new corresponding mozilla-
 beta branch and apply our patches on top? That will probably mean creating
 many branches, but I guess it's ok. Maybe an alternative would be reusing
 mozilla-beta branches for a while by merging the newer changes and not
 trying to keep our patches in the top, and only create a new rebased
 branch for big changes (e.g. releases). But I guess creating a new branch
 for every `geckoview_beta` is simpler and, assuming the potentially large
 number of branches is not an issue, preferable.

 I was also thinking about the `merge day` steps for `android-components`,
 especially this `engine-gecko-nightly` -> `engine-gecko-beta` -> `engine-
 gecko` folder renaming. I was not sure how this would affect us in case we
 have patches to some of those `components/browser/engine-gecko*` folder.
 But since for now we are only going to use `gecko-beta`, we will only
 (possibly) patch `components/browser/engine-gecko-beta`, so the only thing
 is that we probably will have to resolve conflicts due to the merge_day
 `engine-gecko-nightly` -> `engine-gecko-beta` renames. I hope there are no
 weird issues with the git rebase automatic rename detection, like some
 patch being applied to `engine-gecko` instead of `engine-gecko-beta`, but
 hopefully we will catch that if it happens :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33184#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online