That's not the same thing. "uplift" for that page means "backport from development trunk to a more-stable branch".

Theoretically Tor Browser's fork is just another development branch of Firefox, just like Mozilla's primary development branch, and they are "uplifting/backporting" individual patches into stable the same way Mozilla might backport crucial dev-branch improvements/bugfixes into stable.

But they aren't landing patches on "stable", but on the upstream development branch (i.e. mozilla-inbound/central). Since it seems more reasonable to view tor browser as a release branch of firefox than as a development branch, it seems like they are using "uplift" in the opposite sense to the normal Mozilla usage i.e. they are taking a patch from a product branch and moving it to a development branch. In that context "upstream" might indeed be a less confusing choice of words.

On the other hand I think it's clear what they actually mean here, so probably not worth worry about too much.

That page doesn't explain the use of "uplift" to mean what's commonly called "upstreaming". That page refers to "uplift" meaning a patch being added to an older Firefox branch ahead of normal whole-branch promotion. (I.e. cherry pickin from the Nightly channel to Aurora, Beta or even Release ahead of Nightly as a whole becoming the new Aurora, etc.)

Truth said, I can't find an explanation/definition of what actually an "uplift" means there?

It looks like this page is designed for people who already know what an "uplift" is, but wish to implement it properly. That being said, it also appears that "uplifts" will include bug fixes made in Tor Browser and sent upstream to Firefox, rather than just features added (but disabled by default) as was implied in the OP article. I would have assumed that bug fixes made in a downstream product would already have a mechanism to find their way to Firefox. Maybe "uplift" was the term all along for that mechanism, or is a rebranding of it?

Uplift to us is bringing the patches into mozilla-central pref'd off so that Tor developers can just pref features on, rather than re-merge patches for each major and dot release. We also add tend to add tests.

Typically landing a patch on a release branch, "uplifting" it from the main development branch (but occasionally uplifting it from thin air into the release branch).

The article describes it as upstream patch that is disabled by default which allow Firefox to be less discriminative when it comes to accepting patches.

That sentence did not read to me as a definition, and the sentence still works for me using the normal "upstreamed".

"uplift" in this context seemed to mean to me that they were not upstreaming the patches verbatim but neutering them for Firefox.

It's a mix. Some patches are just getting rebased and landed. For others, the Firefox and Tor Browser teams are working together to re-implement the feature in a way that makes more sense in the broader Firefox architecture.

For example, for First Party Isolation, we took the "origin attributes" feature that we built to support containers (user-specified tracking limitations) and reused it for isolation. In the containers case, origins get tagged with a user-specified label; with First Party Isolation, they get tagged with the top-level origin.

And to be clear, there's no "neutering" going on here. We're adding the full features that Tor Browser has, since the whole point of this exercise is to let Tor Browser user preference changes instead of patches. That means that the full capability of the Tor Browser features are in Firefox if users want to enable them.

Regarding your last sentence, does that mean that in the future I could open a link in a 'tor browser' container? That's awesome if so.

Speaking as someone who is familiar with some parts of the Firefox architecture or concepts thereof, but not the source code itself: If you were to implement per-container pref overrides, theoretically yes. AFAIK, prefs are global right now. I don't know if it's feasible to implement this in Fx or if that will leak through to the chrome (process).

But it's an interesting idea! Would you mind filing a bug at bugzilla.mozilla.org?

And will the default for 'Private Browsing' be a Tor container?