Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-02-14T10:20:22Zhttps://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/41814Change "vanilla bridge:" to "Tor bridge:" in bridge cards2024-02-07T13:05:28ZdonutsChange "vanilla bridge:" to "Tor bridge:" in bridge cards"vanilla" is internal jargon, may not localize well and likely confuses users. Can we swap it with a more generic fallback for bridge cards to `Tor bridge:` instead please?
![conjure-bridge-card-alpha](/uploads/6227f30e85bfdef212304d58f..."vanilla" is internal jargon, may not localize well and likely confuses users. Can we swap it with a more generic fallback for bridge cards to `Tor bridge:` instead please?
![conjure-bridge-card-alpha](/uploads/6227f30e85bfdef212304d58f448dcaf/conjure-bridge-card-alpha.png)henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42306Tor Browser crashes when extensions popups are opened with Wayland enabled2024-02-06T20:08:48ZCodingThunderTor Browser crashes when extensions popups are opened with Wayland enabled<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
I have `MOZ_ENABLE_WAYLAND=1` set in my environment in order to hint my FireFox installation to use Wayland. With this ...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
I have `MOZ_ENABLE_WAYLAND=1` set in my environment in order to hint my FireFox installation to use Wayland. With this environment variable set, Tor Browser consistently crashes when trying to open NoScript from pinned extensions menu. I haven't tried to reproduce this with other extensions as it can potentially create a unique fingerprint for me.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Install Tor Browser from torproject.org/torbrowser-launcher.
2. Launch tor browser with `MOZ_ENABLE_WAYLAND=1` set as environment variable.
3. Pin NoScript to extensions toolbar from Settings
4. Try opening the NoScript extension.
5. The Tor Browser crashes with no feedback to the user about why the crash occured
### What is the current bug behavior?
**What actually happens.**
Tor Browser crashes without any feedback to the end user. This can be frustrating or also lead people into believing that they have been infected with malware/or they have been compromised. I think this behaviour got introduced with the last update a day or two ago, as I remember opening the NoScript extension once without any issues (not sure if I actually did use NoScript before, as my FireFox installation also has NoScript and I have used both browsers side by side so I might have hallucinated)
### What is the expected behavior?
**What you want to see instead**
Tor Browser should not crash with `MOZ_ENABLE_WAYLAND=1` set. I guess this bug is fixed in later versions of Firefox as I have never come across any crash with Wayland on my FireFox setup. I have been forcing FireFox to use Wayland since a long time and use plugins all the time, and also access them. Since Tor Browser is based on ESR, it might be missing the necessary bug fixes for the same.
Additionally, I think Tor Browser should ignore `MOZ_ENABLE_WAYLAND=1` atleast for the time Wayland is not mainstream, as it can lead to fingerprinting based on specific behavior caused by the display protocol in use, especially with JavaScript enabled. I'm not sure how the fingerprinting would work, but surely changing the display protocol would bring about some specific behavior which may be detected by sophisticated JavaScript.
### Environment
**Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.**
**Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.**
- Tor Browser installed with torbrowser-launcher/torproject.org from extras repository on Arch Linux with KDE Plasma 5 Wayland session (all packages up to date)
- Tor Browser installed with torbrowser-launcher/torproject.org from extras repository on Arch Linux with GNOME Wayland session (this one's pretty much stock with no modifications at all unlike my Plasma 5 session)
### Relevant logs and/or screenshots
I don't know how to obtain logs for the Tor Browser, even when trying to launch Tor Browser from the terminal, Tor Browser seems to (rightfully) detach itself from the terminal, so I could not obtain logs. And for the screenshots, there is simply no point as no feedback is made available to the user. Screen-recording was an option but I do not want to reveal my Tor Browser and/or my Desktop Environment configma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42273Prepare the "bridge" icon for production2024-01-30T19:24:48ZdonutsPrepare the "bridge" icon for productionI created a super quick version here: [Figma / Tor Browser assets / bridge](https://www.figma.com/file/sd4yASXsToxFECsraTlAsw/Tor-Browser-assets?type=design&node-id=122%3A301&mode=design&t=BSRSZc8GO5ieWvFS-1), which you can see in use on...I created a super quick version here: [Figma / Tor Browser assets / bridge](https://www.figma.com/file/sd4yASXsToxFECsraTlAsw/Tor-Browser-assets?type=design&node-id=122%3A301&mode=design&t=BSRSZc8GO5ieWvFS-1), which you can see in use on these designs: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1). However it needs a little refinement – namely the bottom of each stroke should probably be fully rounded, and also descend a little lower past the horizon for optical balance?
The icon should also be compatible with both Acorn and Material Symbols styles, however you may not need to draw two separate icons in this case (I guess stroke width will be the determining factor).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicob2023-11-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41898Establish timeline for year-end donation campaign takeover of about:tor2024-01-30T13:49:12Zal smithEstablish timeline for year-end donation campaign takeover of about:torEach year from ~mid-October through the end of December, the Tor Project runs its year-end fundraising campaign (aka "YEC"). This is the time during which we raise the most money per year from individual donors. A key strategy in this ca...Each year from ~mid-October through the end of December, the Tor Project runs its year-end fundraising campaign (aka "YEC"). This is the time during which we raise the most money per year from individual donors. A key strategy in this campaign is a branded takeover of about:tor (desktop + mobile) that includes the year-end campaign "mini brand," new assets, a fundraising message, and a donate button.
Based on a conversation with @richard and looking at the release calendar (https://nc.torproject.net/apps/calendar/p/Dy5spytzmYoJPieT/dayGridMonth/2023-10-01), my understanding is that there will be an early October TB release and that this will likely be the best release in which to include about:tor YEC takeover assets.
I'd like to make a plan to get the about:tor year-end campaign takeover assets **ready for this early October release**. Ideally, the about:tor takeover would _not_ launch with that release, but would be included in the package. The campaign launch assets would be gated until mid-October, with another gated release early/mid-November.
To put it another way:
* first week of October - TB release
* **Monday, October 16** - gated YEC takeover of about:tor appears
* ~~**Monday, November 13**~~ **Wednesday, November 22, roughly** - second gated YEC takeover of about:tor appears, based on FF release timing and need to push back match confirmation.
All of that being said, I'd like to understand, based on an early October release:
* When should about:tor assets be ready?
* When should strings be delivered to localization? (Maybe that's a question for @emmapeel?)
* What else should we know, provide, or otherwise be prepared to deliver to the Apps team to make this as painless as possible (:wink:)?
@richard please let me know if I missed anything important I should include. cc @nicobYear End Campaign 2023richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41917Make the appearance of letterboxing look more intentional2024-01-30T13:24:57Zma1Make the appearance of letterboxing look more intentionalCurrent letterboxing appearance looks like a buggy window to some users.
We want to make it look more intentional by:
1. adding a shadow to the content area to make it "pop" from the letterboxing background
2. adding a themed gradient t...Current letterboxing appearance looks like a buggy window to some users.
We want to make it look more intentional by:
1. adding a shadow to the content area to make it "pop" from the letterboxing background
2. adding a themed gradient to the letterboxing backgroundma1ma1https://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 @tjrguest475646844guest475646844https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42345Identity difference in exposed functions between private-browsing and normal-...2024-01-18T13:09:53ZThorinIdentity difference in exposed functions between private-browsing and normal-browsing, Tor Browser, Mullvad Browser and Firefox ESRSo I whipped up a new toy to scrape function properties - the list of functions come from window properties (nightly) :smile:
- https://arkenfox.github.io/TZP/tests/functionprops.html
- you can select `All` to get a full list - it's very...So I whipped up a new toy to scrape function properties - the list of functions come from window properties (nightly) :smile:
- https://arkenfox.github.io/TZP/tests/functionprops.html
- you can select `All` to get a full list - it's very boring unless you compare to other releases
So I thought I would compare TB13 vs ESR115 (using a PB window) - because we spoke about how some FP protections in the past have been to kill the API/feature and leave a ticket open "to investigate", which isn't necessarily true given the "few" diffs I see here - I say "few" because it's only a handful of decisions, even though it generates a bunch of noise
diffs to followThorinThorinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42194Blank Net Error page on name resolution failure2024-01-15T16:34:09ZhenryBlank Net Error page on name resolution failureNoticed in tor browser 13.0. Not reproducible in tor browser 12.5, or latest firefox.
## Steps to reproduce
1. Connect to tor.
2. Type in the urlbar "https:xxxxx"
## Result
Net error page is empty apart from a single "Try Again" butt...Noticed in tor browser 13.0. Not reproducible in tor browser 12.5, or latest firefox.
## Steps to reproduce
1. Connect to tor.
2. Type in the urlbar "https:xxxxx"
## Result
Net error page is empty apart from a single "Try Again" button.
## Expect
A not found page.
## Log
Error in stderr:
> [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
>
> JavaScript error: undefined, line 0: Error: Missing host permission for the tab
>
> JavaScript error: resource://gre/modules/URIFixup.sys.mjs, line 626: NS_ERROR_UNKNOWN_PROXY_HOST: Component returned failure code: 0x804b002a (NS_ERROR_UNKNOWN_PROXY_HOST) [nsIDNSService.asyncResolve]
>
> JavaScript error: resource://gre/modules/URIFixup.sys.mjs, line 626: NS_ERROR_UNKNOWN_PROXY_HOST: Component returned failure code: 0x804b002a (NS_ERROR_UNKNOWN_PROXY_HOST) [nsIDNSService.asyncResolve]
>
> JavaScript error: chrome://global/content/aboutNetError.mjs, line 424: InvalidStateError: An exception was thrown
And in the net error page's console:
> Uncaught (in promise) DOMException: An exception was thrown
>
> initPage chrome://global/content/aboutNetError.mjs:424
>
> <anonymous> chrome://global/content/aboutNetError.mjs:1570
It seems that `RPMCheckAlternateHostAvailable` is throwing.ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41021Enable webrtc for base-browser2023-12-19T18:22:19ZrichardEnable webrtc for base-browserWe disable WebRTC in Tor Browser for a few reasons:
1. UDP does not work over tor, so there's no reason to have this component
2. WebRTC in the past has had proxy-bypass bugs exposing the user's real IP
3. WebRTC fails to build for win...We disable WebRTC in Tor Browser for a few reasons:
1. UDP does not work over tor, so there's no reason to have this component
2. WebRTC in the past has had proxy-bypass bugs exposing the user's real IP
3. WebRTC fails to build for windows when using mingw rather than msvc.
With Sponsor 131, point 1 and point 2 (mostly) are no longer issues, which leaves point 3 (failing build).
There is this issue on Mozilla's bugzilla with the current latest known info about this issue:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1393901
The end goal for this issue: We want to be able to build base-browser for Windows, using mingw without the `--disable-webrtc` flag in the mozconfig. And of course, WebRTC features should work.
Fixing this properly will likely require changes to mingw and webrtc, and likely require some nasty debugging in Firefox on Windows.Sponsor 131 - Phase 2 - Privacy BrowserMarco SimonelliMarco Simonellihttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42339Backport Android security fixes from Firefox 121 to 115.6 - based Tor Browser2023-12-19T15:37:49Zma1Backport Android security fixes from Firefox 121 to 115.6 - based Tor Browser<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`
- `$(RR_VERSION)`: the Mozilla def...<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`
- `$(RR_VERSION)`: the Mozilla defined Rapid-Release version; Tor Browser for Android is based off of the `$(ESR_VERSION)`, but Mozilla's Firefox for Android is based off of the `$(RR_VERSION)` so we need to keep track of security vulnerabilities to backport from the monthly Rapid-Release train and our frozen ESR train.
- **Example**: `110`
- `$(PROJECT_NAME)`: the name of the browser project, either `base-browser` or `tor-browser`
- `$(TOR_BROWSER_MAJOR)`: the Tor Browser major version
- **Example**: `12`
- `$(TOR_BROWSER_MINOR)`: the Tor Browser minor version
- **Example**: either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(BUILD_N)`: a project's build revision within a its branch; many of the Firefox-related projects have a `$(BUILD_N)` suffix and may differ between projects even when they contribute to the same build.
- **Example**: `build1`
</details>
**NOTE:** It is assumed the `tor-browser` rebases (stable and alpha) have already happened and there exists a `build1` build tags for both `base-browser` and `tor-browser` (stable and alpha)
### **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) issues (stable and alpha).
### **Security Vulnerabilities Report**: https://www.mozilla.org/en-US/security/advisories/
- Potentially Affected Components:
- `firefox`/`geckoview`: https://github.com/mozilla/gecko-dev
- `application-services`: https://github.com/mozilla/application-services
- `android-components` (ESR 102 only): https://github.com/mozilla-mobile/firefox-android
- `fenix` (ESR 102 only): https://github.com/mozilla-mobile/firefox-android
- `firefox-android`: https://github.com/mozilla-mobile/firefox-android
**NOTE:** `android-components` and `fenix` used to have their own repos, but since November 2022 they have converged to a single `firefox-android` repo. Any backports will require manually porting patches over to our legacy repos until we have transitioned to ESR 115.
- [ ] Go through the `Security Vulnerabilities fixed in Firefox $(RR_VERSION)` report and create a candidate list of CVEs which potentially need to be backported in this issue:
- CVEs which are explicitly labeled as 'Android' only
- CVEs which are fixed in Rapid Release but not in ESR
- 'Memory safety bugs' fixed in Rapid Release but not in ESR
- [ ] Foreach issue:
- Create link to the CVE on [mozilla.org](https://www.mozilla.org/en-US/security/advisories/)
- **Example**: https://www.mozilla.org/en-US/security/advisories/mfsa2023-05/#CVE-2023-25740
- Create link to the associated Bugzilla issues (found in the CVE description)
- Create links to the relevant `gecko-dev`/other commit hashes which need to be backported OR a brief justification for why the fix does not need to be backported
- To find the `gecko-dev` version of a `mozilla-central`, search for a unique string in the relevant `mozilla-central` commit message in the `gecko-dev/release` branch log.
- **NOTE:** This process is unfortunately somewhat poorly defined/ad-hoc given the general variation in how Bugzilla issues are labeled and resolved. In general this is going to involve a bit of hunting to identify needed commits or determining whether or not the fix is relevant.
### CVEs
- [x] [CVE-2023-6869: Content can paint outside of sandboxed iframe](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6869)
- [Bug 1799036](https://bugzilla.mozilla.org/show_bug.cgi?id=1799036)
- **Note**: _NO backport_ (sec low, complicate back-out/fix in a [regression](https://bugzilla.mozilla.org/show_bug.cgi?id=1863402) bug story)
- [x] [CVE-2023-6870: Android Toast notifications may obscure fullscreen event notifications](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6870)
- [Bug 1823316](https://bugzilla.mozilla.org/show_bug.cgi?id=1823316)
- **Note**: Backported (firefox-android!52)
- [x] [CVE-2023-6871: Lack of protocol handler warning in some instances](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6871)
- [Bug 1828334](https://bugzilla.mozilla.org/show_bug.cgi?id=1828334)
- **Note**: _NO backport_ (unlikely issue for us, mozdevs advised against uplift/backport)
- [x] [CVE-2023-6866: TypedArrays lack sufficient exception handling](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6866)
- [Bug 1849037](https://bugzilla.mozilla.org/show_bug.cgi?id=1849037)
- **Note**: _NO backport_ (very complex 3 commits patch w/dependencies, they're tracking 115esr for 122+)
- [x] [CVE-2023-6872: Browsing history leaked to syslogs via GNOME](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6872)
- [Bug 1849186](https://bugzilla.mozilla.org/show_bug.cgi?id=1849186)
- **Note**: _NO backport_ (it's @pierov's uplift we had to disable b/c UX)
- [x] [CVE-2023-6135: NSS susceptible to "Minerva" attack](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6135)
- [Bug 1853908](https://bugzilla.mozilla.org/show_bug.cgi?id=1853908)
- **Note**: _NO backport_ (3rd party, AFAICT we can't do anything about this, but network latency should save our bacon until Moz does)
- [x] [CVE-2023-6873: Memory safety bugs fixed in Firefox 121](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6873)
- [Bug 1855327](https://bugzilla.mozilla.org/show_bug.cgi?id=1855327)
- **Note**: _NO backport_ (undisclosed, no commit found)
- [x] [CVE-2023-6873: Memory safety bugs fixed in Firefox 121](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6873)
- [Bug 1862723](https://bugzilla.mozilla.org/show_bug.cgi?id=1862723)
- **Note**: _NO backport_ (unaffected)
- [x] [CVE-2023-6868: WebPush requests on Firefox for Android did not require VAPID key](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6868)
- [Bug 1865488](https://bugzilla.mozilla.org/show_bug.cgi?id=1865488)
- **Note**: Backported (firefox-android!52)
- [x] [CVE-2023-6862: Use-after-free in nsDNSService](https://www.mozilla.org/en-US/security/advisories/mfsa2023-54/#CVE-2023-6862)
- [Bug 1868042](https://bugzilla.mozilla.org/show_bug.cgi?id=1868042)
- **Note**: _NO backport_ (fixed in 115.6)
### **tor-browser**: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Backport patches to `tor-browser` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto:
- [ ] `base-browser` stable
- [ ] `tor-browser` alpha
- [ ] `base-browser` alpha
- [ ] Sign/Tag commits:
- **Tag**: `$(PROJECT_NAME)-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [ ] `base-browser` stable
- [ ] `tor-browser` stable
- [ ] `base-browser` alpha
- [ ] `tor-browser` alpha
- [ ] Push tags to `upstream`
- **OR**
- [x] No backports
### **application-services**: https://gitlab.torproject.org/tpo/applications/application-services
- **NOTE**: we will need to setup a gitlab copy of this repo and update `tor-browser-build` before we can apply security backports here
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Backport patches to `application-services` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto `application-services` alpha
- [ ] Sign/Tag commits:
- **Tag**: `application-services-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha`
- [ ] `application-services` stable
- [ ] `application-services` alpha
- [ ] Push tags to `upstream`
- **OR**
- [x] No backports
### **android-components (Optional, ESR 102)**: https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- **NOTE**: Since November 2022, this repo has been merged with `fenix` into a singular `firefox-android` repo: https://github.com/mozilla-mobile/firefox-android. Any backport will require a patch rewrite to apply to our legacy `android-components` project.
- [ ] Backport patches to `android-components` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto `android-components` alpha
- [ ] Sign/Tag commits:
- **Tag**: `android-components-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [ ] `android-components` stable
- [ ] `android-components` alpha
- [ ] Push tags to `upstream`
- **OR**
- [x] No backports
### **fenix (Optional, ESR 102)**: https://gitlab.torproject.org/tpo/applications/fenix.git
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- **NOTE**: Since February 2023, this repo has been merged with `android-components` into a singular `firefox-android` repo: https://github.com/mozilla-mobile/firefox-android. Any backport will require a patch rewrite to apply to our legacy `fenix` project.
- [ ] Backport patches to `fenix` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto `fenix` alpha
- [ ] Sign/Tag commits:
- **Tag**: `tor-browser-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [ ] `fenix` stable
- [ ] `fenix` alpha
- [ ] Push tags to `upstream`
- **OR**
- [ ] No backports
### **firefox-android**: https://gitlab.torproject.org/tpo/applications/firefox-android
- [x] Backport any Android-specific security fixes from Firefox rapid-release
- [x] Backport patches to `firefox-android` stable branch
- [x] Open MR
- [x] Merge
- [x] Rebase patches onto `fenix` alpha
- [x] Sign/Tag commits:
- **Tag**: `firefox-android-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [x] `firefox-android` stable
- [x] `firefox-android` alpha
- [x] Push tags to `upstream`
- **OR**
- [ ] No backportsma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42308Update README for tor browser2023-12-19T14:25:57ZhenryUpdate README for tor browserAs a first step, we can replace the README.txt file content that comes from mozilla with our own wiki links.
/cc @clairehurst @dan @ma1 @pierov @richardAs a first step, we can replace the README.txt file content that comes from mozilla with our own wiki links.
/cc @clairehurst @dan @ma1 @pierov @richardhenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42331tb-dev fetch command is missing repository argument2023-12-19T12:32:15Zhenrytb-dev fetch command is missing repository argumentThe `tb-dev` script git fetch commands are missing the upstream repository argument.
Also, we can limit them to just fetch the upstream branch we actually need for the command.The `tb-dev` script git fetch commands are missing the upstream repository argument.
Also, we can limit them to just fetch the upstream branch we actually need for the command.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42303Remove unused "help" button logic in tor dialogs2023-12-19T12:26:19ZhenryRemove unused "help" button logic in tor dialogsThe "help" button for `xul:dialog` was dropped in [bugzilla 1784882](https://bugzilla.mozilla.org/show_bug.cgi?id=1784882), so we can drop our associated logic.The "help" button for `xul:dialog` was dropped in [bugzilla 1784882](https://bugzilla.mozilla.org/show_bug.cgi?id=1784882), so we can drop our associated logic.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42076Theme is visible in options, but shouldn't be2023-12-05T22:05:58ZclairehurstTheme is visible in options, but shouldn't be### Summary
Due to anti finger printing, we don't allow the user to change the theme (its always purple, not dark or light). We have a setting to change the theme that doesn't do anything and should be removed.
### Steps to reproduce:
...### Summary
Due to anti finger printing, we don't allow the user to change the theme (its always purple, not dark or light). We have a setting to change the theme that doesn't do anything and should be removed.
### Steps to reproduce:
1. Launch tor browser for android
2. Connect to tor
3. Tap on the ⋮ button in the bottom right, then navigate to > Settings > Customize and notice that there is a Theme option
### What is the current bug behavior?
There is an option to set the theme to Light, Dark, or to follow the device theme (shown in screenshot below)
### What is the expected behavior?
There should not be an option to set the theme, because we don't use it
### Environment
Which operating system are you using? macOS Ventura 13.5.1, apple M2 Max, Pixel 7 pro API 34 (arm 64 emulator)
Which installation method did you use? Git
### Relevant logs and/or screenshots
![Screenshot_2023-09-05_at_4.25.39_PM](/uploads/6a6e64b952649dd74435333e3d2e02a1/Screenshot_2023-09-05_at_4.25.39_PM.png)clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42292 Draw new icons for Telegram, web and email bridge channels2023-12-05T00:58:18Zdonuts Draw new icons for Telegram, web and email bridge channelsHey @nicob, see the "Telegram", "Web" and "Gmail or Riseup" bridge distribution channels at the bottom-left of this page: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.png
The globe ...Hey @nicob, see the "Telegram", "Web" and "Gmail or Riseup" bridge distribution channels at the bottom-left of this page: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.png
The globe for "Web" makes sense as the default favicon that Fx uses, however could you draw custom icons in the Acorn style for Telegram (i.e. based on their paper plane logo) and Email (i.e. a standard mail icon) please?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicob2023-11-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42274Draw a new "bridge-pass" icon for lox bridges2023-12-04T20:33:23ZdonutsDraw a new "bridge-pass" icon for lox bridgesI've just grabbed an icon from Material Symbols and rotated it 45 degrees as a placeholder in these designs: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A92...I've just grabbed an icon from Material Symbols and rotated it 45 degrees as a placeholder in these designs: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1) (see the top-right of the bridge card for lox bridges). Could you draw a custom icon based on this please @nicob?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicob2023-11-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42013Review Mozilla 1834374: Do not call EmptyClipboard() in nsBaseClipboard destr...2023-12-04T08:05:07ZrichardReview Mozilla 1834374: Do not call EmptyClipboard() in nsBaseClipboard destructorLink: https://bugzilla.mozilla.org/show_bug.cgi?id=1834374
So this patch is correct in terms of the undefined behaviour aspects: by the time the nsBaseClipboard destructor is called on the object, its implementing class's destructor wou...Link: https://bugzilla.mozilla.org/show_bug.cgi?id=1834374
So this patch is correct in terms of the undefined behaviour aspects: by the time the nsBaseClipboard destructor is called on the object, its implementing class's destructor would have already been called, so calling virtual methods is undefined/broken (since they may touch data that has already been destructed).
Now, we *may* still want to call EmptyClipboard() on destruction (but correctly).
To whomever writes this potential patch, please read up on destruction order/virtual destructors so we don't re-introduce undefined behaviour.
@donuts do you think we would want this behaviour gated on private browsing only mode (clearing clipboard on exit).
@ma1 can we clear clipboard contents iff the contents were placed there by the browser?
@ruihildt if we do want this in Tor Browser, do you think we would *also* want this in Mullvad Browser? The fix is new in FF115 so iirc the current Mullvad Browser is clearing the clipboard on exit.ma1ma1