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/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/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/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/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/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/42305(Semi-)Automatically merge translation resources across tor browser releases ...2024-03-26T20:31:08Zhenry(Semi-)Automatically merge translation resources across tor browser releases (desktop)/cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch.../cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch name, and merges the versions found in both branches together with a comment added for strings that will be dropped at the next release. Here is the initial draft of the script if you want a quick look: [combine-translation-versions.py](/uploads/83cf1424566cf3b3222e6a60682bcc56/combine-translation-versions.py)
We could use the output as the `en-US` source files for weblate, combining both the strings needed for the next release as well as for the current stable release. The idea being that in tor-browser we can stop trying to maintain all the old strings in the current development branch that are still needed for the current stable release. And we can avoid having to manual clean ups of old strings, like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42221.
E.g., if we have `tor-browser.ftl` in tor-browser-xxx-13.5 with the content
```
string1 = String 1
new-string = New String
string2 = String 2
```
and in tor-browser-xxx-13.0 with the content
```
old-string = Old String
string1 = String 1
string2 = String 2
```
the script would output
```
string1 = String 1
new-string = New String
string2 = String 2
## Will be unused in Tor Browser 13.5!
old-string = Old String
```
The reason I add the comment is to provide a little notification to weblate translators in the "Source string description" to let them know that a string has a short lifetime. Weblate doesn't support descriptions for `.dtd` though so it won't work for that format.
@emmapeel and @pierov what do you think? And where would we want to run this script?
I guess we basically want to merge the translations files from both the branch used for current nightly and current stable. I'm not sure if this can be automatically pulled from `tor-browser-build` in a convenient way, or whether we would need some manual input.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/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/42222Fix TorDomainIsolator initialization on Android2023-11-06T20:47:38ZPier Angelo VendrameFix TorDomainIsolator initialization on AndroidIn TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don...In TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don't know if it's due to the XPCOM changes that happened between 102 and 115, or if it's just because of the various refactors.
Since we don't have a circuit display, the only way to notice this is going to different sites that show the IP address, and notice that they have the same one, but we'd expect them to be isolated.
Some Tor-friendly ones are:
- https://check.torproject.org/
- https://www.wtfismyip.com/
- https://myip.wtf/ (same as the previous one, but different FP domain for TBB :smile:)
- https://mullvad.net/en/check
When we finally start working on tests we should also have a test that checks circuit FPI.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42214Fluent migration: security level2024-03-26T20:59:30ZhenryFluent migration: security levelMigrate "securityLevel.properties" to Fluent.Migrate "securityLevel.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42211Fluent migration: new identity2024-03-21T09:57:00ZhenryFluent migration: new identityMigrate "newIdentity.properties" to Fluent.Migrate "newIdentity.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42209Fluent migration: tor circuit2024-03-26T13:41:53ZhenryFluent migration: tor circuitMigrate tor circuit strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.Migrate tor circuit strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42203Fluent migration: about dialog2024-03-21T13:33:26ZhenryFluent migration: about dialogMigrate "aboutDialog.dtd" to Fluent.Migrate "aboutDialog.dtd" to Fluent.henryhenryhttps://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/42188Donations are asked repeatedly when I click New identity button2023-11-16T18:27:39ZcypherpunksDonations are asked repeatedly when I click New identity buttonDonations are asked repeatedly when I click New identity button. I already click X on the donation window and I expect it to hide from now but you insisted on displaying it over and over.Donations are asked repeatedly when I click New identity button. I already click X on the donation window and I expect it to hide from now but you insisted on displaying it over and over.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42184Setting "Homepage and new windows" ignores "Blank Page" value2023-11-26T15:38:20Zpf.teamSetting "Homepage and new windows" ignores "Blank Page" valueSteps to reproduce:
1. Run TB 13.0.
2. Open: about:preferences#home
3. Set "Homepage and new windows" to the "Blank Page" value.
4. Restart TB.
Environment: Linux (x86_64).
Expected result: a new TB instance shows about:blank page.
A...Steps to reproduce:
1. Run TB 13.0.
2. Open: about:preferences#home
3. Set "Homepage and new windows" to the "Blank Page" value.
4. Restart TB.
Environment: Linux (x86_64).
Expected result: a new TB instance shows about:blank page.
Actual result: a new TB instance shows about:tor page.henryhenry