I wonder if a more consistent location would be just before "TB 2176: Rebrand Firefox to TorBrowser". That's where we make other shared UI changes.

Moreover, if you are running ./mach lint on a CSS file, you will want "TB 41817: tor-browser semantic styling" to be included so that stylelint will recognise the tor CSS colour tokens as being valid. Therefore, if you are running the linter as you step through a rebase/cherry-pick, it would be handy to have this before any of the "TB" commits that add CSS.

NOTE: Currently the stylelint token stuff is switched off, but we have plans to re-enable it once mozilla has cleaned up the linter.

Should this be an amend! instead of a fixup!?

I don't think so. I think you already renamed it in !1913 (merged), so the commit message doesn't need rewording again.

@any1here sorry to put a halt on your contribution. From a quick look, the logic looks ok. However, this change involves a change in UX, which means:

1. It has not yet been decided that we do want this feature. We have to balance whether this is resolving an issue that is worth the ongoing maintenance (which is non-trivial since this is embedded in mozilla code, which does change over time and will break the patch). Do you have any insights into how common or severe the issue you are trying to solve is?
2. This may need some UX input. No one from the UX team has been CCed in the issue #294, and no decisions about a solution were agreed to.

Note that I will make this change soon, as part of #43570.

@felicia and @donuts I'm currently implementing this. After some time with this, I will tweak the wording a little bit to make the language less ambiguous without using jargon either.

In particular, I'm thinking of:

• Switching "Tor daemon" with "Tor process". The word "daemon" is very uncommon, and isn't even universally used when discussing the tor program. I think "process" is much more familiar. Moreover, anyone who does have a technical understanding would know what this is referring to.
• Switching "Tor-powered application" with "application that uses the Tor network". This is drier but clearer in meaning.
• Switching "Tor" (without a suffix) with "Tor process". I.e. "The Tor process has stopped working", "Restart Tor process". In our existing strings, "Tor" without a suffix can refer to either the "Tor network", the "Tor program" or "Tor Project". In those existing places, the ambiguity doesn't usually matter. But in this case I think the word "Tor" by itself is likely to be misinterpreted, and it will be confusing to the user why they get taken from a page that says "Tor isn't working properly" to "Connect to Tor", where the former refers to the process and the latter is the network. Therefore, I think we should clear up the ambiguity for the new page, and use "Tor process", even though it is more verbose.

I can copy you in on the merge request to iron out the wording, and we can update the android wording to match when that work is done.

I think it makes sense to include the potential threats under the "adversaries" section. But the "mitigations" section is TBD right now.

Ah ok, thanks for letting me know the background. That is interesting. My guess is that the prettier step of the command in the buildtokens script failed because it was incorrectly configured or not installed.

In any case, it worked out in the end, so I'm not too worried.

changes to that commit between the various revisions of the MR

oh right, in the following change: !1913 (diffs)

Yes, I've been running ./mach lint --fix on those files, as there was some lint errors.

The new change seems to be what I would expect from ./mach buildtokens. It shouldn't need any linting.

I'm not sure how the previous state, pre linting, was reached.

@boklm did something go wrong with ./mach buildtokens in the rebase? This is the first rebase that has required it, so I wonder what happened.

It could be that the commit needs to be pushed higher up the stack, so that ./mach can be run correctly with that commit checked out.

@pierov Some changes to toolkit/themes/shared/design-system/dist/ are to be expected, since these are generated files. See the comment in the commit 95088e8f. If the instructions in the commit were followed, it should be fine.

Otherwise, if there are changes to other files that are unexplained, then I can review it.

henry how does a redesign like this work in terms of front-end? Is there a way for you to just "pull" the updates from Firefox to Tor Browser or will you need to build every UI element from scratch?

We don't need to build every UI element from scratch. Mozilla has some pre-set widgets (moz-toggle, moz-checkbox, etc) which we can use for our own settings. I think the components listed in the acorn design desktop web page are more or less in line with the widgets available to developers. In general, if we use the mozilla widgets/components we can inherit all the styling and behaviour with very little work.

For anything that is more custom, like the bridge grid (also know as "bridge cards"), I think we will still be able to use our own custom elements. And I believe we can mostly reuse the styling, markup and code that we already have. Maybe with some shuffling around, but it wouldn't need to be a full rebuild.

I'm asking this just so I understand if you'd need 1) full mockups of every screen or maybe 2) just mockups of parts of Settings that are specific from Tor Browser.

We definitely do not need full mockups. Based on what I wrote in #259 (comment 3353960), I only want mockups for replacing:

1. The current security level display and the "Change…" button.

2. The Connection "Internet:" and "Tor network:" status display.

3. The "Your bridges" box when using a built-in bridge.

4. The "Your bridges" box when using some other bridge source (bridge grid display). Lox bridges can be ignored since they are disabled.

5. The "Find more bridges" section. The list with "Telegram", "Web" and "Gmail or Riseup", and the bridge-bot aside. Although you may want to expand the scope of the mockup to also include the "Select a built-in bridge…" and "Replace bridges…" buttons. E.g. if you want to follow the same design as "Cookies and Site Data" and group these into one using a box group component.

Notes:

• All of our other settings in the main page have an obvious Mozilla component we can switch to, so a mockup isn't needed by me. Although you may still want to mock up some of them for yourself for the "Connection" settings if you want to visualise the whole page as one.
• For the sub-dialogs (onion authentication keys, security level switcher, bridge qr code, built-in bridge, user-provided bridge, request bridge, Tor connection settings, Tor log), I have not yet seen what mozilla has planned for their own dialogs. I'm not sure if they are planning on moving away from dialogs entirely to use sub-pags instead (e.g. like about:preferences#profiles). Unless you know already, I think we can wait and see what happens in Firefox first. I don't think these dialogs will be that hard to convert.
• Even in the above cases I already listed, it would be ok to skip the mockup if you want our custom component to remain the same as it is in 15.0.

So, overall, I don't need many mockups since a chunk of the changes will be obvious to switch over, and we're going to inherit most of the styling from Mozilla anyway. So just do as many mockups as you find useful for yourself!

I've related this issue to #44714 (closed), since I think this change caused that problem, based on this comment:

Unfortunately it seems that because of the about:blank loading changes occurred recently in Firefox RR, a race condition prevents the fallback from working correctly.

On android the TorProvider uses TorProcessAndroid in toolkit/components/tor-launcher/TorProcessAndroid.sys.mjs, which is what communicates with the android integration.

henry (f2031d01) at 17 Mar 10:54

... and 8 more commits

in TorAndroidIntegration.java there is a BootstrapStateChangeListener interface and assorted calls. Already uses the Stage api internally so it works but do we want to rename it to Stage as well. Should be fast and easy, and then just a few minor changes in TorControllerGV.kt as well 😄

TBH I'm not entirely sure how much of the android naming is meant to line up with the shared backend. E.g. in this case it would probably more like TorConnectStageChangeListener, since not all stages are "bootstrap"-related stages. And I imagine there are other things that are similarly mis-aligned.

I'll leave it up to the android developers to implement these renaming changes since it is kind of outside my domain, and I'm not sure it is worth your time to rename stuff right now.

Explained by #44702 (comment 3362174).

Merge Info

Issues

Resolves

• #514
• tor-browser#xxxxx
• tor-browser-build#xxxxx

Related

• mullvad-browser#xxxxx
• tor-browser#44720
• tor-browser-build#xxxxx

Merging

Target Branches

• mullvad-browser - !fixups to mullvad-browser-specific commits, new features, security backports
• base-browser and tor-browser - !fixups to base-browser-specific commits or new features to be shared with tor-browser
  • ⚠️ IMPORTANT: Please list the base-browser-specific commits which need to be cherry-picked to the base-browser and tor-browser branches here

Target Channels

• Alpha: rapid release, 16.0
• Stable: esr140-15.0

Backporting

Timeline

• No Backport (preferred): patchset for the next major stable
• Immediate: patchset needed as soon as possible (fixes CVEs, 0-days, etc)
• Next Minor Stable Release: patchset that needs to be verified in nightly before backport
• Eventually: patchset that needs to be verified in alpha before backport

(Optional) Justification

• Security update: patchset contains a security fix (be sure to select the correct item in Timeline)
• Critical bug-fix: patchset fixes a bug in core-functionality
• Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
• Sponsor required: patchset required for sponsor
• Localization: typos and other localization changes that should be also in the release branch
• Other: please explain

Upstream

• Patchset is a candidate for uplift to Firefox
• Patchset is a backport from Firefox
  • Bugzilla link:
  • Upstream commit:

Issue Tracking

• Link resolved issues with appropriate Release Prep issue for changelog generation

Review

Request Reviewer

• Request review from an applications developer depending on modified system:
  • NOTE: if the MR modifies multiple areas, please /request_review all the relevant reviewers
  • accessibility : henry
  • android : clairehurst, dan
  • build system : boklm
  • ci/cd: brizental, henry
  • extensions : ma1
  • firefox internals (XUL/JS/XPCOM) : jwilde, ma1
  • fonts : pierov
  • frontend (implementation) : henry
  • frontend (review) : donuts, morgan
  • localization : henry, pierov
  • macOS : clairehurst, dan
  • nightly builds : boklm
  • rebases/release-prep : brizental, clairehurst, dan, ma1, pierov, morgan
  • security : jwilde, ma1
  • signing : boklm, morgan
  • updater : pierov
  • windows : jwilde, morgan
  • misc/other : pierov, morgan

Change Description

Adaptation of tor-browser!1903.

How Tested

No errors due to the button migration, no new identity anywhere.

I wonder if you could change get AIFeature in TranslationsParent.sys.mjs to return

return { isEnabled: false };

It seems to be the only property that is currently read. Probably needs a follow up though.