Opened 9 months ago

Last modified 5 months ago

#33184 assigned enhancement

Support for Fenix

Reported by: sisbell Owned by: gk
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, TorBrowserTeam202006
Cc: tbb-team Actual Points:
Parent ID: #33659 Points:
Reviewer: Sponsor: Sponsor58-must

Description

Track issues and discussion related to Fenix support, including toolchain.

Project located at: https://github.com/mozilla-mobile/fenix

Child Tickets

TicketTypeStatusOwnerSummary
#33556taskassignedgkAdd TBB project for android-components
#33557taskmerge_readygkUpdate Android Toolchain for Fenix
#33558defectmerge_readygkUpdate TOPL To Use Updated Android Toolchain
#33559defectmerge_readygkUpdate tor-android-service To Use Updated Android Toolchain
#33561defectmerge_readygkUpgrade openssl to use Android NDK 20
#33562defectclosedgkUpgrade libevent to use NDK 20
#33563defectmerge_readygkUpgrade Tor To Use Android NDK 20
#33564defectmerge_readytbb-teamUpgrade ZSTD to use Android NDK 20
#33565defectclosedtbb-teamUpgrade LZMA to use Android NDK 20
#33594tasknewtbb-teamFenix Use of Glean
#33626taskneeds_reviewgkAdd TBB project for GeckoView
#33760defectneeds_reviewgkUpdate rbm.conf to match NDK 20
#33801defectmerge_readytbb-teamUpgrade Go Project to use new Android Toolchain
#33833defectneeds_reviewgkUpgrade Rust To Use Android NDK 20
#33927defectassignedgkAdd tor-browser-build project for fenix
#33934defectnewtbb-teamFix Fenix reproducibility issues
#33973taskmerge_readygkCreate fat .aar for geckoview
#34011defectneeds_reviewgkBump clang version to 9.0.1
#34012defectneeds_reviewgkBump cbindgen version to 0.14.1
#34013defectneeds_revisiongkBump node version to v10.21.0
#34014defectneeds_reviewgkSupport sqlite3 in our python project
#34101defectassignedgkAdd tor-browser-build project for application-services
#34108taskassignedgkWrite script to keep track of toolchain changes
#34187defectmerge_readygkUpdate zlib build script to pick up new android toolchain
#34432taskassignedgkIntegrate fenix toolchain into tor-browser-build's master

Change History (25)

comment:1 Changed 9 months ago by sisbell

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team

comment:2 Changed 9 months ago by sisbell

So this first issue we have to resolve is this one

https://github.com/mozilla-mobile/fenix/issues/6932

Fenix doesn't build out-of-the-box on a clean clone of the repo.

comment:3 Changed 8 months ago by sisbell

Cc: boklm added; bolklm removed

comment:4 in reply to:  2 Changed 8 months ago by sisbell

Replying to sisbell:

So this first issue we have to resolve is this one

https://github.com/mozilla-mobile/fenix/issues/6932

Fenix doesn't build out-of-the-box on a clean clone of the repo.

This caused by not having ANDROID_SDK_HOME and ANDROID_NDK_HOME properties set. Since this is handled by the android-toolchain setup, its not a problem for the tbb build.

comment:5 Changed 8 months ago by sisbell

This is preview. It has similar problems as #33556 with working with network disabled. You can see in the gradle-dependencies-list there are a bunch of snapshots for the android-components. These snapshot hashes will change without warning so those will be replaced with the ones that will be packaged locally from the tbb android-components build.

https://github.com/sisbell/tor-browser-build/commits/bug-33184

comment:6 Changed 8 months ago by sisbell

Cc: eighthave removed

I'm working through this using tbb android-components generated artifacts as dependencies. I haven't checked in the changes as I'm still working through but what I have found its

We can modify buildSrc/src/main/java/Dependencies.kt to match android-components dependencies we build

const val mozilla_android_components = "36.0.0"

I removed a number of projects from android-components so those references have to be removed from as dependencies in app/build.gradle

I also added legacy plugin support, same as in android-components

The telemetry can be easily disabled for runtime, will require a simple patch. I still will need to verify the impact on compile time, having removed the artifact dependencies as well.

There's also a number of build variants to we can configure for beta, nightly and some others which add debugging builds, etc.

fenix uses SDK 28 (while toolchain, android-components uses 29). I'll align these.

comment:7 in reply to:  6 Changed 6 months ago by gk

Replying to sisbell:

I'm working through this using tbb android-components generated artifacts as dependencies. I haven't checked in the changes as I'm still working through but what I have found its

We can modify buildSrc/src/main/java/Dependencies.kt to match android-components dependencies we build

const val mozilla_android_components = "36.0.0"

I removed a number of projects from android-components so those references have to be removed from as dependencies in app/build.gradle

I also added legacy plugin support, same as in android-components

The telemetry can be easily disabled for runtime, will require a simple patch. I still will need to verify the impact on compile time, having removed the artifact dependencies as well.

There's also a number of build variants to we can configure for beta, nightly and some others which add debugging builds, etc.

fenix uses SDK 28 (while toolchain, android-components uses 29). I'll align these.

I just realized this is not just a meta ticket (as indicated by the description). It seems, though, just the one extra patch is not enough anymore (just declaring mavenLocal() is not making it for me). There are issues with aligning the SDKs as well (see comment:13:ticket:33557). Let's keep this as meta ticket and use #33927 for the Fenix tor-browser-build changes?

If you want to work on the fenix part (again) let me know. I was under the assumption you'd focus on the geckoview part currently and picked this up.

comment:8 Changed 6 months ago by gk

Here come some release cycle notes I collected that should help us determine which combinations of components we want to base our nightly and release builds on:

The release cycle for mozilla-* code is 4 weeks which means 3 weeks 3 betas each and one week with 3 rcs (affects GeckoView)

For Fenix we have beta and nightly versions with geckoview on beta/nightly. In particular Mozilla builds

a) nightly: geckoBeta/fenixNightly and geckoNightly/fenixNightly (only latter is published to Google Play)
b) beta: geckoBeta/fenixBeta
c) production: geckoBeta/fenixProducion

(Yes, the release version of GeckoView is currently not used it seems)

android-components used on Fenix master is updated daily by a bot to the latest nightly version

geckoview used on android-components' master is updated daily by a bot to the latest nightly version and to the latest beta every 2-4 days (I suspect that corresponds to the 3 betas each week above)

See: docs/contribute/merge_day.md for what happens during merge days in the android-components repository.

How does branching and release tagging for Fenix currently look like?

4.3 release

  • branching off 1 week before release (7f1ef17d8b4b6aa5381819ef7a7ab822668b05c1 merge-base with master), no beta releases before that and android-components got pinned to a stable version for release on first beta which got out 3 days before the final release

4.2 release

  • branching off 1 day before release (301f56d144754e6c26f7e390952f35287185dfd4 merge-base with master), no beta releases before that and android-components got pinned to a stable for release on first beta which got out 1 days before the final release

comment:9 Changed 6 months ago by gk

So, based on comment:8 I think what we do is base our fenix nightly build on a fixed fenix commit from the master branch and build geckoBetaFenixNightly. We update the commit a couple of times during a release cycle which needs in turn an update for the android-components nightly commit we build from (that is is needs to match match the respective fenix nightly is currently using). That is turns needs rebased patches to the geckoview beta we use.

A challenge will be all the Gradle dep updates every time and the different set of Gradle deps we now have to maintain for the nightly and the stable series.

Last edited 6 months ago by gk (previous) (diff)

comment:10 Changed 6 months ago by gk

We *could* think about building geckoBetaDebug but maybe that's more for devs actually debugging Fenix code than our nightly audience

comment:11 in reply to:  9 ; Changed 6 months ago by sysrqb

Replying to gk:

Here come some release cycle notes I collected

Thanks for analyzing this.

Replying to gk:

So, based on comment:8 I think what we do is base our fenix nightly build on a fixed fenix commit from the master branch and build geckoBetaFenixNightly. We update the commit a couple of times during a release cycle which needs in turn an update for the android-components nightly commit we build from (that is is needs to match match the respective fenix nightly is currently using). That is turns needs rebased patches to the geckoview beta we use.


Let's see. Let's assume we only maintain Tor Browser "Nightly" and "Release" channels in the future. I agree that our nightly builds should be based on a "recent" version of fenixNightly (and this will probably become fennecNightly, in the future). I'm fine with beginning with using geckoBeta for the nightly builds, at least initially. Skipping ahead a few weeks, at the end of the current month, our Nightly branch becomes the new Beta. We aren't planning on publishing the beta channel at this point, but we should continue updating the Fenix commit (from the correct branch, along with the new required AC/GV dependencies) as bugs are fixed during the beta cycle. We should continue running the tests on this branch (geckoBetaFenixBeta), despite not releasing it. At the end of the following month, the beta branch becomes the new Release. I assume Fenix will add a geckoRelease in the future. That will lead to building geckoReleaseFenixRelease on release days.

For our nightly builds, we can think about moving onto geckoNightly later this year. Using geckoBeta as a more stable base seems like a safe foundation for us, because we'll be dealing with many other moving parts and components.

This means we'll take "snapshots" periodically of the many repositories we need (mozilla-beta, android-components, fenix, etc.) and we'll rebase our patches on top of the tip/head commit at that point in time (or an older commit, if that makes more sense). As we are following all three Fenix release trains, we'll need to follow this process for (up to) 9 branches (possibly 2 mozilla-beta branches , a mozilla-release branch, possibly 3 android-components branches, and 3 fenix branches). We may be able to simplify this into 1 mozilla-beta branch such that fenixNightly and fenixBeta use the same version of GV for geckoBeta. We probably can't escape maintaining three patchsets for android-components. However, with all of this said, the "release" patchsets should only be rebased and used a few times during the month, if there are any point releases - and only once in general. So, "9 branches" is really "only" rebasing 5-6 branches periodically.

This process sounds exhausting. We should think about how we can automate some of these. We can automate the "snapshot-and-rebase" piece of it (and this fits into the auto-rebasing plan we already have), and then we only deal with the merge conflicts, as needed. The test suites can be triggered when the rebasing is completed, as well.

A challenge will be all the Gradle dep updates every time and the different set of Gradle deps we now have to maintain for the nightly and the stable series.

It would be nice if we can automate this process, too. And, I suppose, this is a prerequisite for automatically running the test suites after each rebase, as well.

Replying to gk:

We *could* think about building geckoBetaDebug

What does this build? That isn't a valid target, from what I see. Do you mean simply debug or something like that? I think we shouldn't use non-debuggable builds for nightly, at least at the beginning. I prefer following Mozilla's lead on this until we're comfortable with our configuration and we know what we're doing.

comment:12 in reply to:  11 Changed 6 months ago by gk

Replying to sysrqb:

[snip]

Replying to gk:

We *could* think about building geckoBetaDebug

What does this build? That isn't a valid target, from what I see. Do you mean simply debug or something like that? I think we shouldn't use non-debuggable builds for nightly, at least at the beginning. I prefer following Mozilla's lead on this until we're comfortable with our configuration and we know what we're doing.

It's the default target which Mozilla is suggesting in ./gradlew clean app:assembleGeckoBetaDebug. I am not sure what it builds in Fenix land it says just debug. My guess, though is it's using Fenix nightly code.

Last edited 6 months ago by gk (previous) (diff)

comment:13 in reply to:  11 ; Changed 6 months ago by gk

Replying to sysrqb:

Replying to gk:

Here come some release cycle notes I collected

Thanks for analyzing this.

Replying to gk:

So, based on comment:8 I think what we do is base our fenix nightly build on a fixed fenix commit from the master branch and build geckoBetaFenixNightly. We update the commit a couple of times during a release cycle which needs in turn an update for the android-components nightly commit we build from (that is is needs to match match the respective fenix nightly is currently using). That is turns needs rebased patches to the geckoview beta we use geckoBeta/fenixProduction.


Let's see. Let's assume we only maintain Tor Browser "Nightly" and "Release" channels in the future. I agree that our nightly builds should be based on a "recent" version of fenixNightly (and this will probably become fennecNightly, in the future). I'm fine with beginning with using geckoBeta for the nightly builds, at least initially. Skipping ahead a few weeks, at the end of the current month, our Nightly branch becomes the new Beta. We aren't planning on publishing the beta channel at this point, but we should continue updating the Fenix commit (from the correct branch, along with the new required AC/GV dependencies) as bugs are fixed during the beta cycle. We should continue running the tests on this branch (geckoBetaFenixBeta), despite not releasing it. At the end of the following month, the beta branch becomes the new Release. I assume Fenix will add a geckoRelease in the future. That will lead to building geckoReleaseFenixRelease on release days.

Maybe. I guess it's still up in the air how this will develop. I think we should follow closely what the Fenix project is using right now keeping in mind to amend our plans as things evolve.

That means e.g. there is no beta branch on Fenix whatsoever right now. Moreover, as I pointed out above, Fenix beta releases and regular releases are essentially the same: there is no week between them. So, given the current state of affairs we are stuck with building geckoBetaFenixNightly (or geckoBetaDebug assuming that means FenixNightly) for our nightlies and once Fenix is moving to beta (that is a *release* branch is created) we have the sole option to have one or two builds testing the upcoming release config (with the stable android-components) from that branch before we need to use the geckoBetaFenixProduction flavor.

For our nightly builds, we can think about moving onto geckoNightly later this year. Using geckoBeta as a more stable base seems like a safe foundation for us, because we'll be dealing with many other moving parts and components.

Moving to geckoNightly means we need to start rebasing our patches to mozilla-central and not onto mozilla-beta anymore (there is no point using geckoNightly when we build geckoview from mozilla-beta) which is currently not planned according to S58 at least. We likely need to have our automatic rebasing setup for that. Thus, I am skeptical that we get to using a geckoNightly flavor going this year, especially as we'll have S30 work in parallel and we are only 3 people. But, yes, in the glorious future it seems worth thinking about how we can switch to geckoNightly so that our nightly users are testing that.

This means we'll take "snapshots" periodically of the many repositories we need (mozilla-beta, android-components, fenix, etc.) and we'll rebase our patches on top of the tip/head commit at that point in time (or an older commit, if that makes more sense). As we are following all three Fenix release trains, we'll need to follow this process for (up to) 9 branches (possibly 2 mozilla-beta branches , a mozilla-release branch, possibly 3 android-components branches, and 3 fenix branches). We may be able to simplify this into 1 mozilla-beta branch such that fenixNightly and fenixBeta use the same version of GV for geckoBeta. We probably can't escape maintaining three patchsets for android-components. However, with all of this said, the "release" patchsets should only be rebased and used a few times during the month, if there are any point releases - and only once in general. So, "9 branches" is really "only" rebasing 5-6 branches periodically.

The same "Maybe" as above. Again, right now I am mostly interested in figuring out what we need for a setup to get the whole machine going in, say, the next couple of weeks. As to branches that we currently (and in the coming couple of weeks) need, I think, we are at:

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).

This process sounds exhausting. We should think about how we can automate some of these. We can automate the "snapshot-and-rebase" piece of it (and this fits into the auto-rebasing plan we already have), and then we only deal with the merge conflicts, as needed. The test suites can be triggered when the rebasing is completed, as well.

I am somewhat optimistic that only the geckoview part is timeconsuming, and actually, that's likely only to happen once a new mozilla-central comes down into the beta branch. Apart from that the changes should not be that big (mozilla-beta) or the code base is just not a large/problematic (android-components/fenix). Although, the latter will highly depend on how much and what we need to patch out/change.

A challenge will be all the Gradle dep updates every time and the different set of Gradle deps we now have to maintain for the nightly and the stable series.

It would be nice if we can automate this process, too. And, I suppose, this is a prerequisite for automatically running the test suites after each rebase, as well.

Not just the testsuites but getting the whole thing to build again, yes. I suspect we'll be mostly good for the non-master (that is releases) branches but looking at some of those there are sometimes updates on them that make it necessary as well to recreate the dependencies.

comment:14 Changed 6 months ago by pili

Sponsor: Sponsor58-must

comment:15 in reply to:  13 ; Changed 6 months ago by acat

Replying to 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 :)

comment:16 Changed 6 months ago by pili

Parent ID: #33659

Parenting to S58 O2.2

comment:17 Changed 6 months ago by gk

Cc: sysrqb boklm removed
Keywords: Android removed

comment:18 in reply to:  15 Changed 6 months ago by gk

Replying to acat:

Replying to 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?

Yes, that's the state of things for now at least.

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.

So first, the android-components model is similar to the Fenix one I mentioned in comment:8: There is only the master branch in that project and then some release branches/tags. And the releases I checked (v39.0 and v37.0) are directly made from the master branch. If there is a need for point releases (as for v37.0.X) they are made from the respective release branch.

Second, the pacemaker for us is our ability to keep up with geckoview beta rebasing (and then reviewing and testing the results before pushing that to our repo for nightly builds) given that it will involve the vast majority of our patches. I don't remember whether we decided on a frequency for those rebases yet but for the sake of argument let's assume that means once per week.

So, let's start with b1 on a Monday like today where nightly goes to beta (it seems b1 is getting released the same day or maybe one day later). We rebase our geckoview patches for that. Let's assume it takes until Thursday until we have this reviewed and ready for nightlies. It seems on android-components the merge day happens one day after the Mozilla merge day. Either way, once android-components has picked b1 up we rebase our patches for android-components and use the commit where b1 got picked. And once Fenix picks up that commit we do the same with our Fenix patches. I assume the whole process will take the first week in the new cycle. And then we repeat (even though we might a bit faster subsequently in the process)

All in all I'd assume one new branch per repo per beta we use. I think that's not too crazy.

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 :)

Well, I'd expect the majority of conflicts to come from the android-components merge day, yes. That is in the first week of the geckoview release cycle. But there are a bunch of changes that makes it to engine-gecko-beta outside of the merge day changes. So, I'd expect whenever we pick up a new android-components commit (due to a new mozilla beta) we'll have some (smaller) conflict resolution to do.

(Note: this is all without having the application-services included, but *if* we need to include parts of that code, too, I don't think the overall picture outlined above will change substantially)

comment:19 Changed 6 months ago by gk

Keywords: TorBrowserTeam202005 added
Priority: MediumVery High

comment:20 Changed 6 months ago by gk

To continue what I wrote in comment:8: Fenix 5.0 is out:

5.0 release

  • branching off 2 days before release (2c18c255da0bdcc48ec7deda3ce64b97797cce75 merge base with master), no beta releases before that and android-components got pinned to a stable version (39.0.0) for first beta, which got out two days before 5.0.

Noteworthy as well that the release cycle is not aligned to the one for GeckoView but it seems to the one for android-components instead.

Last edited 6 months ago by gk (previous) (diff)

comment:21 Changed 6 months ago by gaba

Owner: changed from tbb-team to gk
Status: newassigned

comment:22 Changed 5 months ago by acat

I noticed that there is the EARLY_BETA_OR_EARLIER define which controls several prefs, for example the one controlling whether SharedArrayBuffer is enabled or not (not implying that SharedArrayBuffer is still dangerous, just as an example). And by taking a look at the latest Fenix releases:

v4.1.0
36.0.2
75.0.20200309155231
EARLY_BETA_OR_EARLIER=1
has SharedArrayBuffer
v4.2.0
37.0.0
75.0.20200322132212
EARLY_BETA_OR_EARLIER=
does not have SharedArrayBuffer
v4.3.0
38.0.0
76.0.20200406152003
EARLY_BETA_OR_EARLIER=1
has SharedArrayBuffer
v5.0.0
39.0.1
76.0.20200424000239
EARLY_BETA_OR_EARLIER=
does not have SharedArrayBuffer

I'm not sure if it's intended that there is one Fenix version with early beta and another with late beta alternatively, or it is a coincidence. This might not be an issue if they are going to move to gecko-release for Fenix release, but just mentioning it here just in case we want to take a look at these kind of issues. With some pinning tests like the dom_enumeration ones, but for prefs we should probably be able to catch these issues, so that might be a good idea to have for Fenix.

comment:23 Changed 5 months ago by acat

Cc: tbb-team added

comment:24 in reply to:  22 Changed 5 months ago by gk

Replying to acat:

I noticed that there is the EARLY_BETA_OR_EARLIER define which controls several prefs, for example the one controlling whether SharedArrayBuffer is enabled or not (not implying that SharedArrayBuffer is still dangerous, just as an example). And by taking a look at the latest Fenix releases:

v4.1.0
36.0.2
75.0.20200309155231
EARLY_BETA_OR_EARLIER=1
has SharedArrayBuffer
v4.2.0
37.0.0
75.0.20200322132212
EARLY_BETA_OR_EARLIER=
does not have SharedArrayBuffer
v4.3.0
38.0.0
76.0.20200406152003
EARLY_BETA_OR_EARLIER=1
has SharedArrayBuffer
v5.0.0
39.0.1
76.0.20200424000239
EARLY_BETA_OR_EARLIER=
does not have SharedArrayBuffer

I'm not sure if it's intended that there is one Fenix version with early beta and another with late beta alternatively, or it is a coincidence. This might not be an issue if they are going to move to gecko-release for Fenix release, but just mentioning it here just in case we want to take a look at these kind of issues. With some pinning tests like the dom_enumeration ones, but for prefs we should probably be able to catch these issues, so that might be a good idea to have for Fenix.

Indeed, it is. What you see stems from the fact that the release cycles between GeckoView and Fenix are not aligned (yet). So, we need to catch those issues. I heard the plan is to align those cycles at some point (and Fenix release using GeckoView release etc.), though, but it's not clear when exactly this will happen and how we would deal with that.

comment:25 Changed 5 months ago by gk

Keywords: TorBrowserTeam202006 added; TorBrowserTeam202005 removed

Moving tickets to June.

Note: See TracTickets for help on using tickets.