Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-28T18:43:11Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42490Install svg from branding theme to browser/chrome/icons/default2024-03-28T18:43:11ZboklmInstall svg from branding theme to browser/chrome/icons/defaultIn
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/943#note_3013584,
@PieroV mentioned that we have svg files (added in commits `Bug 2176:
Rebrand Firefox to TorBrowser` and `MB 1: Mullvad Browser brandi...In
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/943#note_3013584,
@PieroV mentioned that we have svg files (added in commits `Bug 2176:
Rebrand Firefox to TorBrowser` and `MB 1: Mullvad Browser branding`),
but we currently don't install them to `browser/chrome/icons/default`.
If we do that we can then update the debian package to link them from
`/usr/share/icons/hicolor/scalable/apps`.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42489Lox module notifications2024-03-28T10:07:16ZhenryLox module notificationsCurrently the Lox module does not give out notifications for when its internals change, so:
+ `TorSetting` is not notified when the bridges change. So it is only set to the new value when restarting Tor Browser.
+ "about:preferences" is...Currently the Lox module does not give out notifications for when its internals change, so:
+ `TorSetting` is not notified when the bridges change. So it is only set to the new value when restarting Tor Browser.
+ "about:preferences" is not notified when the invites change or when there is a blockage or upgrade event.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42480Use translation CI in android2024-03-26T17:22:26ZhenryUse translation CI in androidhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42305 added some CI for automatically moving strings from `tor-browser` (desktop) to the translation repository.
The CI and bot seem to be working well, so I think we c...https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42305 added some CI for automatically moving strings from `tor-browser` (desktop) to the translation repository.
The CI and bot seem to be working well, so I think we can do the same in android.
/cc @pierov @dan @clairehursthenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42479Switch from localized strings to error codes in TorConnect errors2024-03-28T17:23:09ZPier Angelo VendrameSwitch from localized strings to error codes in TorConnect errorsAs noted in !938, we try to translate some error messages in `TorConnect`.
However, it isn't great, because:
1. it's backend, localized strings don't belong there
2. it's backend, we need to pass stuff usable by the frontends in code (...As noted in !938, we try to translate some error messages in `TorConnect`.
However, it isn't great, because:
1. it's backend, localized strings don't belong there
2. it's backend, we need to pass stuff usable by the frontends in code (especially important for Android), it's the frontend's role to transform it in something for the users
3. for Android, this part of the code lives in GeckoView, which we currently don't translatePier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42466Drop the "Onion Logo" from trademark statement2024-03-27T11:07:18ZhenryDrop the "Onion Logo" from trademark statementCurrently, in the "About Tor Browser" dialog, we have the statement:
> `“Tor” and “The Onion Logo” are registered trademarks of The Tor Project, Inc.`
We don't actually use the trademarked onion logo in our builds any more. See the tra...Currently, in the "About Tor Browser" dialog, we have the statement:
> `“Tor” and “The Onion Logo” are registered trademarks of The Tor Project, Inc.`
We don't actually use the trademarked onion logo in our builds any more. See the trademark here: https://tsdr.uspto.gov/#caseNumber=77172363&caseSearchType=US_APPLICATION&caseType=DEFAULT&searchType=statusSearch
I've searched through our assets and I can't find this old logo, which I think was cleared out with the new designs from UX. @donuts can you please confirm we won't use the logo any more?
So I think we should change it to:
> `“Tor” is a registered trademark of The Tor Project, Inc.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42459Add startpage onion service to list of search providers2024-03-26T21:17:06ZrichardAdd startpage onion service to list of search providersStartpage has added a new onion service, so lets add it to the list of built-in search providers.
URL: http://startpagel6srwcjlue4zgq3zevrujfaow726kjytqbbjyrswwmjzcqd.onion/
We'd like this in the next stable release 13.0.12 and the nex...Startpage has added a new onion service, so lets add it to the list of built-in search providers.
URL: http://startpagel6srwcjlue4zgq3zevrujfaow726kjytqbbjyrswwmjzcqd.onion/
We'd like this in the next stable release 13.0.12 and the next alpha release 13.5a6Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42458Update the "Submit Feedback" link in "About Tor Browser"2024-03-26T21:14:46Zebanamebanam@torproject.orgUpdate the "Submit Feedback" link in "About Tor Browser"The link in "Submit Feedback", visible in `Help` > `About Tor Browser`, currently points to https://support.torproject.org/get-in-touch/. I think we can make it point to https://support.torproject.org/misc/bug-or-feedback/ directly instead.The link in "Submit Feedback", visible in `Help` > `About Tor Browser`, currently points to https://support.torproject.org/get-in-touch/. I think we can make it point to https://support.torproject.org/misc/bug-or-feedback/ directly instead.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42452Allow restoring bridge pass (Lox credentials) with the same invite2024-03-12T12:26:19ZhenryAllow restoring bridge pass (Lox credentials) with the same inviteWe want to support the following in Tor Browser:
1. A user redeems an invite to get new lox credentials.
2. Later, they remove the Lox bridges.
3. The user re-inputs the *same* invite.
In this case, we should restore their credentials ...We want to support the following in Tor Browser:
1. A user redeems an invite to get new lox credentials.
2. Later, they remove the Lox bridges.
3. The user re-inputs the *same* invite.
In this case, we should restore their credentials after step 3 using our Lox cache. Bypassing the Lox authority.
@donuts or @cohosh, do you see any potential problems with allowing this?henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42449Rebase Tor Browser alpha onto Firefox 115.9.0esr2024-03-26T20:31:21ZPier Angelo VendrameRebase Tor Browser alpha onto Firefox 115.9.0esr**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
- `$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building...**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
- `$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- **Example**: `102.8.0`
- `$(ESR_TAG)`: the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- **Example**: `FIREFOX_102_8_0esr_RELEASE`
- `$(ESR_TAG_PREV)`: the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
- **Example**: `FIREFOX_102_7_0esr_BUILD1`
- `$(BROWSER_MAJOR)`: the browser major version
- **Example**: `12`
- `$(BROWSER_MINOR)`: the browser minor version
- **Example**: either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(BASE_BROWSER_BRANCH)`: the full name of the current `base-browser` branch
- **Example**: `base-browser-102.8.0esr-12.5-1`
- `$(BASE_BROWSER_BRANCH_PREV)`: the full name of the previous `base-browser` branch
- **Example**: `base-browser-102.7.0esr-12.5-1`
- `$(TOR_BROWSER_BRANCH)`: the full name of the current `tor-browser` branch
- **Example**: `tor-browser-102.8.0esr-12.5-1`
- `$(TOR_BROWSER_BRANCH_PREV)`: the full name of the previous `tor-browser` branch
- **Example**: `tor-browser-102.7.0esr-12.5-1`
</details>
**NOTE:** It is assumed that we've already identified the new ESR branch during the tor-browser stable rebase
### **Bookkeeping**
- [ ] Link this issue to the appropriate [Release Prep](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Release%20Prep) issue.
### Update Branch Protection Rules
- [ ] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository):
- [ ] Remove previous alpha `base-browser` and `tor-browser` branch protection rules (this will prevent pushing new changes to the branches being rebased)
- [ ] Create new `base-browser` and `tor-browser` branch protection rule:
- **Branch**: `*-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1*`
- **Example**: `*-102.8.0esr-12.5-1*`
- **Allowed to merge**: `Maintainers`
- **Allowed to push and merge**: `Maintainers`
- **Allowed to force push**: `false`
- If you copied and pasted from old rules, double check you didn't add spaces at the end, as GitLab will not trim them!
### **Create New Branches**
- [ ] Find the Firefox mercurial tag `$(ESR_TAG)`
- If `$(BROWSER_MINOR)` is 5, the tag should already exist from the stable release
- Otherwise:
- [ ] Go to `https://hg.mozilla.org/releases/mozilla-esr$(ESR_MAJOR)/tags`
- [ ] Find and inspect the commit tagged with `$(ESR_TAG)`
- Tags are in yellow in the Mercurial web UI
- [ ] Find the equivalent commit in `https://github.com/mozilla/gecko-dev/commits/esr$(ESR_MAJOR)`
- The tag should be very close to `HEAD` (usually the second, before a `No bug - Tagging $(HG_HASH) with $(ESR_TAG)`)
- **Notice**: GitHub sorts commits by time, you might want to use `git log gecko-dev/esr$(ESR_MAJOR)` locally, instead
- [ ] Sign/Tag the `gecko-dev` commit: `git tag -as $(ESR_TAG) $(GIT_HASH) -m "Hg tag $(ESR_TAG)"`
- [ ] Create new alpha `base-browser` branch from Firefox mercurial tag
- Branch name in the form: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1`
- **Example**: `base-browser-102.8.0esr-12.5-1`
- [ ] Create new alpha `tor-browser` branch from Firefox mercurial tag
- Branch name in the form: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1`
- **Example**: `tor-browser-102.8.0esr-12.5-1`
- [ ] Push new `base-browser` branch to `upstream`
- [ ] Push new `tor-browser` branch to `upstream`
### **Rebase tor-browser**
- [ ] Checkout a new local branch for the `tor-browser` rebase
- **Example**: `git branch tor-browser-rebase FIREFOX_102_8_0esr_BUILD1`
- [ ] **(Optional)** `base-browser` rebase and autosquash
- **NOTE** This step may be skipped if the `HEAD` of the previous `base-browser` branch is a `-buildN` tag
- [ ] Cherry-pick the previous `base-browser` commits up to `base-browser`'s `buildN` tag onto new `base-browser` rebase branch
- **Example**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..base-browser-102.7.0esr-12.5-1-build1`
- [ ] Rebase and autosquash these cherry-picked commits
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_BUILD1 HEAD`
- [ ] Cherry-pick remainder of patches after the `buildN` tag
- **Example**: `git cherry-pick base-browser-102.7.0esr-12.5-1-build1..upstream/base-browser-102.7.0esr-12.5-1`
- [ ] `tor-browser` rebase and autosquash
- [ ] Note the current git hash of `HEAD` for `tor-browser` rebase+autosquash step: `git rev-parse HEAD`
- [ ] Cherry-pick the appropriate previous `tor-browser` branch's commit range up to the last `tor-browser` `buildN` tag
- **Example**: `git cherry-pick base-browser-102.7.0esr-12.5-1-build1..tor-browser-102.7.0esr-12.5-1-build1`
- **Example (if separate base-browser rebase was skipped)**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..tor-browser-102.7.0esr-12.5-1-build1`
- [ ] Rebase and autosquash **ONLY** these newly cherry-picked commits using the commit noted previously: `git rebase --autosquash --interactive $(PREV_HEAD)`
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [ ] **(Optional)** Patch reordering
- **NOTE**: We typically want to do this after new features or bug fix commits which are not !fixups to an existing commit have been merged and are just sitting at the end of the commit history
- Relocate new `base-browser` patches in the patch-set to enforce this rough thematic ordering:
- **MOZILLA BACKPORTS** - official Firefox patches we have backported to our ESR branch: Android-specific security updates, critical bug fixes, worthwhile features, etc
- **MOZILLA REVERTS** - revert commits of official Firefox patches
- **UPLIFT CANDIDATES** - patches which stand on their own and should be uplifted to `mozilla-central`
- **BUILD CONFIGURATION** - tools/scripts, gitlab templates, etc
- **BROWSER CONFIGURATION** - branding, mozconfigs, preference overrides, etc
- **SECURITY PATCHES** - security improvements, hardening, etc
- **PRIVACY PATCHES** - fingerprinting, linkability, proxy bypass, etc
- **FEATURES** - new functionality: updater, UX, letterboxing, security level, add-on
- Relocate new `tor-browser` patches in the patch-set to enforce this rough thematic ordering:
- **BUILD CONFIGURATION** - tools/scripts, gitlab templates, etc
- **BROWSER CONFIGURATION** - branding, mozconfigs, preference overrides, etc
- **UPDATER PATCHES** - updater tweaks, signing keys, etc
- **SECURITY PATCHES** - non tor-dependent security improvements, hardening, etc
- **PRIVACY PATCHES** - non tor-dependent fingerprinting, linkability, proxy bypass, etc
- **FEAURES** - non tor-dependent features
- **TOR INTEGRATION** - legacy tor-launcher/torbutton, tor modules, bootstrapping, etc
- **TOR SECURITY PATCHES** - tor-specific security improvements
- **TOR PRIVACY PATCHES** - tor-specific privacy improvements
- **TOR FEATURES** - new tor-specific functionality: manual, onion-location, onion service client auth, etc
- [ ] Cherry-pick remainder of patches after the last `tor-browser` `buildN` tag
- **Example**: `git cherry-pick tor-browser-102.7.0esr-12.5-1-build1..upstream/tor-browser-102.7.0esr-12.5-1`
- [ ] Rebase and autosquash again, this time replacing all `fixup` and `squash` commands with `pick`. The goal here is to have all of the `fixup` and `squash` commits beside the commit which they modify, but kept un-squashed for easy debugging/bisecting.
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [ ] Compare patch sets to ensure nothing *weird* happened during conflict resolution:
- [ ] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred difftool and look at differences on lines that starts with + or -
- `git diff $(ESR_TAG_PREV)..$(BROWSER_BRANCH_PREV) > current_patchset.diff`
- `git diff $(ESR_TAG)..$(BROWSER_BRANCH) > rebased_patchset.diff`
- diff `current_patchset.diff` and `rebased_patchset.diff`
- If everything went correctly, the only lines which should differ should be the lines starting with `index abc123...def456` (unless the previous `base-browser` branch includes changes not included in the previous `tor-browser` branch)
- [ ] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..HEAD`
- **Example**: `git range-dif FIREFOX_102_7_0esr_BUILD1..upstream/tor-browser-102.7.0esr-12.5-1 FIREFOX_102_8_0esr_BUILD1..HEAD`
- [ ] Open MR for the `tor-browser` rebase
- [ ] Merge
- Update and push `base-browser` branch
- [ ] Reset the new `base-browser` branch to the appropriate commit in this new `tor-browser` branch
- [ ] Push these commits to `upstream`
- [ ] Set `$(TOR_BROWSER_BRANCH)` as the default GitLab branch
- [ ] Go to [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository)
- [ ] Expand `Branch defaults`
- [ ] Set the branch and leave the `Auto-close` checkbox unchecked
- [ ] Save changes
### **Sign and Tag**
- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch:
- **Tag**: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
- **Message**: `Tagging build1 for $(ESR_VERSION)esr-based alpha`
- [ ] Push tag to `upstream`
- [ ] Sign/Tag HEAD of the merged `base-browser` branch:
- **Tag**: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
- **Message**: `Tagging build1 for $(ESR_VERSION)esr-based alpha`
- [ ] Push tag to `upstream`
- [ ] Update tor-browser-build's main (no MR required, you can just push it if you have the permissions)
- [ ] Update `projects/firefox/config`
- [ ] Update `firefox_platform_version`
- [ ] Set `browser_build` to 1 (to prevent failures in alpha testbuilds)
- [ ] Update `projects/geckoview/config`
- [ ] Update `geckoview_version`
- [ ] Set `browser_build` to 1Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42448Rebase Tor Browser stable onto Firefox 115.9.0esr2024-03-13T08:08:26ZPier Angelo VendrameRebase Tor Browser stable onto Firefox 115.9.0esr**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
- `$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building...**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
- `$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- **Example**: `102.8.0`
- `$(ESR_TAG)`: the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- **Example**: `FIREFOX_102_8_0esr_RELEASE`
- `$(ESR_TAG_PREV)`: the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
- **Example**: `FIREFOX_102_7_0esr_BUILD1`
- `$(BROWSER_MAJOR)`: the browser major version
- **Example**: `12`
- `$(BROWSER_MINOR)`: the browser minor version
- **Example**: either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(BASE_BROWSER_BRANCH)`: the full name of the current `base-browser` branch
- **Example**: `base-browser-102.8.0esr-12.0-1`
- `$(BASE_BROWSER_BRANCH_PREV)`: the full name of the previous `base-browser` branch
- **Example**: `base-browser-102.7.0esr-12.0-1`
- `$(TOR_BROWSER_BRANCH)`: the full name of the current `tor-browser` branch
- **Example**: `tor-browser-102.8.0esr-12.0-1`
- `$(TOR_BROWSER_BRANCH_PREV)`: the full name of the previous `tor-browser` branch
- **Example**: `tor-browser-102.7.0esr-12.0-1`
</details>
### **Bookkeeping**
- [x] Link this issue to the appropriate [Release Prep](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Release%20Prep) issue.
### Update Branch Protection Rules
- [ ] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository):
- [ ] Remove previous stable `base-browser` and `tor-browser` branch protection rules (this will prevent pushing new changes to the branches being rebased)
- [ ] Create new `base-browser` and `tor-browser` branch protection rule:
- **Branch**: `*-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1*`
- **Example**: `*-102.8.0esr-12.0-1*`
- **Allowed to merge**: `Maintainers`
- **Allowed to push and merge**: `Maintainers`
- **Allowed to force push**: `false`
### **Identify the Firefox Tagged Commit and Create New Branches**
- [ ] Find the Firefox mercurial tag here: https://hg.mozilla.org/releases/mozilla-esr102/tags
- **Example**: `FIREFOX_102_8_0esr_BUILD1`
- [ ] Find the analogous `gecko-dev` commit: https://github.com/mozilla/gecko-dev
- **Tip**: Search for unique string (like the Differential Revision ID) found in the mercurial commit in the `gecko-dev/esr102` branch to find the equivalent commit
- **Example**: `3a3a96c9eedd02296d6652dd50314fccbc5c4845`
- [ ] Sign and Tag `gecko-dev` commit
- Sign/Tag `gecko-dev` commit :
- **Tag**: `$(ESR_TAG)`
- **Message**: `Hg tag $(ESR_TAG)`
- [ ] Create new stable `base-browser` branch from tag
- Branch name in the form: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1`
- **Example**: `base-browser-102.8.0esr-12.0-1`
- [ ] Create new stable `tor-browser` branch from
- Branch name in the form: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1`
- **Example**: `tor-browser-102.8.0esr-12.0-1`
- [ ] Push new `base-browser` branch to `upstream`
- [ ] Push new `tor-browser` branch to `upstream`
- [ ] Push new `$(ESR_TAG)` to `upstream`
### **Rebase tor-browser**
- [ ] Checkout a new local branch for the `tor-browser` rebase
- **Example**: `git branch tor-browser-rebase FIREFOX_102_8_0esr_BUILD1`
- [ ] **(Optional)** `base-browser` rebase
- **NOTE** This step may be skipped if the `HEAD` of the previous `base-browser` branch is a `-buildN` tag
- [ ] Cherry-pick the previous `base-browser` commits up to `base-browser`'s `buildN` tag onto new `base-browser` rebase branch
- **Example**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..base-browser-102.7.0esr-12.0-1-build1`
- [ ] Rebase and autosquash these cherry-picked commits
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_BUILD1 HEAD`
- [ ] Cherry-pick remainder of patches after the `buildN` tag
- **Example**: `git cherry-pick base-browser-102.7.0esr-12.0-1-build1..upstream/base-browser-102.7.0esr-12.0-1`
- [ ] `tor-browser` rebase
- [ ] Note the current git hash of `HEAD` for `tor-browser` rebase+autosquash step: `git rev-parse HEAD`
- [ ] Cherry-pick the appropriate previous `tor-browser` branch's commit range up to the last `tor-browser` `buildN` tag
- **Example**: `git cherry-pick base-browser-102.7.0esr-12.0-1-build1..tor-browser-102.7.0esr-12.0-1-build1`
- **Example (if separate base-browser rebase was skipped)**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..tor-browser-102.7.0esr-12.0-1-build1`
- [ ] Rebase and autosquash these newly cherry-picked commits: `git rebase --autosquash --interactive $(PREV_HEAD)`
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [ ] Cherry-pick remainder of patches after the last `tor-browser` `buildN` tag
- **Example**: `git cherry-pick tor-browser-102.7.0esr-12.0-1-build1..upstream/tor-browser-102.7.0esr-12.0-1`
- [ ] Rebase and autosquash again, this time replacing all `fixup` and `squash` commands with `pick`. The goal here is to have all of the `fixup` and `squash` commits beside the commit which they modify, but kept un-squashed for easy debugging/bisecting.
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [ ] Compare patch sets to ensure nothing *weird* happened during conflict resolution:
- [ ] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred difftool and look at differences on lines that starts with + or -
- `git diff $(ESR_TAG_PREV)..$(BROWSER_BRANCH_PREV) > current_patchset.diff`
- `git diff $(ESR_TAG)..$(BROWSER_BRANCH) > rebased_patchset.diff`
- diff `current_patchset.diff` and `rebased_patchset.diff`
- If everything went correctly, the only lines which should differ should be the lines starting with `index abc123...def456` (unless the previous `base-browser` branch includes changes not included in the previous `tor-browser` branch)
- [ ] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..HEAD`
- **Example**: `git range-dif FIREFOX_102_7_0esr_BUILD1..upstream/tor-browser-102.7.0esr-12.0-1 FIREFOX_102_8_0esr_BUILD1..HEAD`
- [ ] Open MR for the `tor-browser` rebase
- [ ] Merge
- Update and push `base-browser` branch
- [ ] Reset the new `base-browser` branch to the appropriate commit in this new `tor-browser` branch
- [ ] Push these commits to `upstream`
### **Sign and Tag**
- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch:
- **Tag**: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
- **Message**: `Tagging build1 for $(ESR_VERSION)esr-based stable`
- [ ] Push tag to `upstream`
- [ ] Sign/Tag HEAD of the merged `base-browser` branch:
- **Tag**: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
- **Message**: `Tagging build1 for $(ESR_VERSION)esr-based stable`
- [ ] Push tag to `upstream`Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42446Improve accessible descriptions in built-in dialog2024-03-26T20:42:37ZhenryImprove accessible descriptions in built-in dialogCurrently the "Current bridge" label is present in the aria description for the radio options, even if the label is hidden.
Moreover, the "Current bridge" text is concatenated with the rest of the description, without any punctuation se...Currently the "Current bridge" label is present in the aria description for the radio options, even if the label is hidden.
Moreover, the "Current bridge" text is concatenated with the rest of the description, without any punctuation separation.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42441Evaluate RR version-by-RR version rebases instead of ESR-to-ESR2024-03-27T11:06:13ZPier Angelo VendrameEvaluate RR version-by-RR version rebases instead of ESR-to-ESRTraditionally, we're switching from a Firefox ESR version to the next one.
I've done this work twice now, and I can see some of the problems it involves.
First, at a certain point we have to focus this change and we're in a sort of lim...Traditionally, we're switching from a Firefox ESR version to the next one.
I've done this work twice now, and I can see some of the problems it involves.
First, at a certain point we have to focus this change and we're in a sort of limbo with patches developed for the previous ESR while we're already rebasing, and the rebaser has to catch a lot.
Second, the rebase is a lot of work, but reviewing it is also a big one.
Third, we have a lots of conflicts.
In 13 Firefox versions, it's very likely that a commit is going to cause conflicts.
Because the long time it takes to do this work, last year I decided to start when 115 started nightly.
It gave us 2 additional months, which was great, considering it raised our budget from 3 months to 5 months.
I thought if I could do better, and I came up with the idea of traversing RR version by RR version, and I've started to do so.
My impression is that differences are much smaller, therefore easier to explain.
Also, it's a work we can spread during the year, and we can be ready to move to the build/Android parts sooner (even though also for Android we could do something similar), or in any case give some of the 5 months time to all members of the team.
I can see some disadvantages (and limits) also with this approach:
- it's possible that with 13 rebases instead of just a few ones we lose more parts of the patches
- possibly more (easy) conflicts to solve, so they might require more time at the end, than solving only one big conflict (but I'm not sure, I don't have metrics)
- I've gone with a quick approach: I haven't solved non-trivial problems that involve fixing a patch, and I haven't tried to build/run
- more load on the team (more reviews to do, if we end up not taking the quick way we might have to work on build problems every month)
- as an alternative, the reviews could be done with a lower frequency, or even when we arrive to our final target (it will be a huge review on one shot, but at least it will be possible to find when something has changed more easily, by going through my notes)
- I started from 115.x and go back to 115.0 to then go through the mozilla/release branch. I had a few conflicts because of the various backports. Starting this work as soon as possible would help with this.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42437Drop "torbrowser.version" preference2024-03-26T20:27:58ZhenryDrop "torbrowser.version" preference"torbrowser.version" is defined based on `__BASE_BROWSER_VERSION_QUOTED__`, but is only used in one place: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/8614325290175a7253f11501d823db65ab805257/browser/components/abou..."torbrowser.version" is defined based on `__BASE_BROWSER_VERSION_QUOTED__`, but is only used in one place: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/8614325290175a7253f11501d823db65ab805257/browser/components/abouttor/AboutTorMessage.sys.mjs#L30.
But we could just use the existing "browser.startup.homepage_override.torbrowser.version" instead.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42425Improve accessibility of the bridge emoji cells2024-03-04T15:14:34ZhenryImprove accessibility of the bridge emoji cellsWhen testing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413 with screen readers I noticed:
+ NVDA does not like to read the table cell accessible name, but will instead read the content of the cell only.
+ Orc...When testing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413 with screen readers I noticed:
+ NVDA does not like to read the table cell accessible name, but will instead read the content of the cell only.
+ Orca will not read the `aria-describedby` in a table.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42421Remove bridge option should be hidden for Lox bridges2024-03-04T15:14:03ZhenryRemove bridge option should be hidden for Lox bridgesCurrently we allow individual Lox bridges to be removed through the "Bridge options" menu.Currently we allow individual Lox bridges to be removed through the "Bridge options" menu.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42415Improve focus styling for forced focus in bridge settings2024-02-14T10:21:05ZhenryImprove focus styling for forced focus in bridge settingsAs part of https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036, I set up a few places where we wanted to move focus to the start of an area by calling `.focus` on an element with `tabindex = -1`. This issue is just ...As part of https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036, I set up a few places where we wanted to move focus to the start of an area by calling `.focus` on an element with `tabindex = -1`. This issue is just to tidy up some of the focus styling of these elements for these rare moments where they have `:focus-visible`.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42414Show ellipsis when the tor bridge address overflows2024-02-14T10:20:22ZhenryShow ellipsis when the tor bridge address overflowsCurrently the ellipsis doesn't show, as intended in the mockup: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-added.pngCurrently the ellipsis doesn't show, as intended in the mockup: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-added.pnghenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42390Betterboxing: make the decorator border disappear when the corners are flat2024-02-08T14:48:36Zma1Betterboxing: make the decorator border disappear when the corners are flatReported by @thorin, who provided also the screenshot: the decorator line from #42387, which should usually blend with the letterboxing background, is unpleasantly visible when the window is at letterboxing-rounded size.
Since the decor...Reported by @thorin, who provided also the screenshot: the decorator line from #42387, which should usually blend with the letterboxing background, is unpleasantly visible when the window is at letterboxing-rounded size.
Since the decorator is useful only when the corners are rounded, and we auto-flatten them whenever the letterboxing margin is less than the rounded corners radius, we can hide the decorator as soon as the corner are flattened and bring it back when they're rounded again.
While we're here, per @donuts 's request, we'll remove the thin shadow separating the toolbar from the browser content, originally implemented in https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/886#note_2984761.
![image](/uploads/d71b4fefac2cce27f0ecb62d18a6b909/image.png)ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42389Betterboxing: gradient is never shown2024-02-07T17:58:03ZThorinBetterboxing: gradient is never shownwindows: theme is system auto (and OS is dark) cc: @ma1
![lbgradient](/uploads/91b640d9aa2a359bceb4616b2e1c4acc/lbgradient.png)windows: theme is system auto (and OS is dark) cc: @ma1
![lbgradient](/uploads/91b640d9aa2a359bceb4616b2e1c4acc/lbgradient.png)ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42354Refactor exclusions in ShouldSanitizePreference() to the pref list.2024-01-30T10:45:22Zguest475646844Refactor exclusions in ShouldSanitizePreference() to the pref list.This is second issue related to MR !765 which requires uplifting changes to upstream as per Tom's [suggestion](https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/765#note_2943521 "Draft: Bug 41165: Onion rewrite ...This is second issue related to MR !765 which requires uplifting changes to upstream as per Tom's [suggestion](https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/765#note_2943521 "Draft: Bug 41165: Onion rewrite static pref causes a crash in debug builds"):
> ```plaintext
> tjr | my suggestion would be to make a new override list, move these prefs
> | (https://searchfox.org/mozilla-central/source/modules/libpref/Preferences.cpp#6137-6143) into it, along with your pref.
> ```
Please refer to original MR for details. I'll update code comments and post it here.
/cc @pierov @tjrguest475646844guest475646844