The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-03T13:29:12Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41935Improve new window & letterboxing dimensions2023-10-03T13:29:12ZrichardImprove new window & letterboxing dimensionsMeta issue for our various letterboxing issues we should fix in ~"13.0 stable":
- [ ] ~~Change the default start window size from 1000x1000 mullvad-browser#175~~ (duplicate of the below ticket)
- [x] Increase max width of new windows to...Meta issue for our various letterboxing issues we should fix in ~"13.0 stable":
- [ ] ~~Change the default start window size from 1000x1000 mullvad-browser#175~~ (duplicate of the below ticket)
- [x] Increase max width of new windows tor-browser#33282
- [x] Re-evaluate letterboxing dimension choices tor-browser#30556
Let's plan on doing this work in base-browser so tor-browser can get these improvements also.ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41876Remove Firefox View from title bar2023-10-03T17:15:56ZhenryRemove Firefox View from title barI'm guessing we don't want the `firefox-view-button` in the title bar. We can remove it in the "Bug 41736: Customize toolbar for base-browser." patch.I'm guessing we don't want the `firefox-view-button` in the title bar. We can remove it in the "Bug 41736: Customize toolbar for base-browser." patch.https://gitlab.torproject.org/tpo/applications/torbrowser-launcher/-/issues/11Update copyright name2024-01-10T17:49:39ZasciiwolfUpdate copyright nameWe should probably change the torbrowser-launcher copyright that gets printed on stdout when the launcher is started to `Tor Project` or something similar:
```
$ grep "By Micah Lee" * -R
...
torbrowser_launcher/__init__.py: print(_("...We should probably change the torbrowser-launcher copyright that gets printed on stdout when the launcher is started to `Tor Project` or something similar:
```
$ grep "By Micah Lee" * -R
...
torbrowser_launcher/__init__.py: print(_("By Micah Lee, licensed under MIT"))
torbrowser_launcher.pot:msgid "By Micah Lee, licensed under MIT"
```
/cc @boklmboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40984Circuit Display not shown in some cases2023-08-22T17:49:18ZAlex CatarineuCircuit Display not shown in some casesTo reproduce:
1. Search something via URL bar or about:tor.
2. When DDG page loads, click to show Circuit Display.
3. Open new browser window.
4. Repeat 1 and 2: Circuit Display is not shown.
This might be related to legacy/trac#30290,...To reproduce:
1. Search something via URL bar or about:tor.
2. When DDG page loads, click to show Circuit Display.
3. Open new browser window.
4. Repeat 1 and 2: Circuit Display is not shown.
This might be related to legacy/trac#30290, but did not investigate yet.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41842Remove the old removal logics from Torbutton2023-10-03T13:29:23ZPier Angelo VendrameRemove the old removal logics from Torbuttontorbutton@2dfa0e0c9cff7cfad93664e0b0b6cdc05b24b7f2 introduced some logic to remove old files (`$profile/cookies|protected-*.json`) that aren't used anymore.
However, after the 12.0 watershed, we don't need it for sure anymore.
Also, th...torbutton@2dfa0e0c9cff7cfad93664e0b0b6cdc05b24b7f2 introduced some logic to remove old files (`$profile/cookies|protected-*.json`) that aren't used anymore.
However, after the 12.0 watershed, we don't need it for sure anymore.
Also, there is a function to mess with preferences that we don't need anymore.
So, as part of the great torbutton cleanup, remove all of this.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41813Look out for links missing underlines in ESR 115-based alphas2023-10-03T13:29:30ZdonutsLook out for links missing underlines in ESR 115-based alphasIt looks like Fx is going to switch back to an underlined link style in ~"FF115-esr". Hopefully any custom links we've created are using the right CSS classes and this change happens automagically for us, but I'm opening this ticket to t...It looks like Fx is going to switch back to an underlined link style in ~"FF115-esr". Hopefully any custom links we've created are using the right CSS classes and this change happens automagically for us, but I'm opening this ticket to track any outliers we may find.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41870Modern firewall-penetration protocols for Tor in China2023-07-07T10:01:53ZcomputerscotModern firewall-penetration protocols for Tor in ChinaReports on https://github.com/net4people/bbs/issues and https://forum.torproject.org say that both obfs4 and snowflake are blocked by the GFW. There are also doubts about whether the new WebTunnel pluggable transport will work. The GFW d...Reports on https://github.com/net4people/bbs/issues and https://forum.torproject.org say that both obfs4 and snowflake are blocked by the GFW. There are also doubts about whether the new WebTunnel pluggable transport will work. The GFW detects and blocks WebSocket-based proxies.
This is a proof-of-concept for more modern firewall-penetration protocols.
To test these protocols in action, set up an Xray server and client using the latest techniques, for example, https://cscot.pages.dev/2023/07/02/xray-reality-h2. If you follow the sample configuration in that article, you will have a SOCKS5 proxy listening on port `10808` on your client.
Download and install the Tor Browser from https://www.torproject.org.
When you run the Tor Browser for the first time, click **Configure Connection**.
Scroll down and click the **Settings** button at the bottom to configure how you connect to the internet. Check **I use a proxy to connect to the Internet**. The type is **SOCKS5**, the address is `127.0.0.1`, and the port is `10808`. Click **OK**.
I have found it more reliable to click **Select a Built-In Bridge**. This should not be necessary, since the Xray server is already outside the GFW. Perhaps it helps because built-in bridges are faster than random entry nodes. Select **obfs4**. Click **Connect**.
Now you can test your connection by trying to reach a Tor-only site.
BBC News in simplified Chinese:
```
https://www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion/zhongwen/simp
```
DW News in simplified Chinese:
```
https://www.dwnewsgngmhlplxy6o2twtfgjnrnjxbegbwqx6wnotdhkzt562tszfid.onion/zh/?zhongwen=simp
```
New York Times in simplified Chinese:
```
https://cn.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion
```
![dw-onion-simplified-chinese](/uploads/c696b775dc1f976880b42e8100342f54/dw-onion-simplified-chinese.png)meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/128Modern firewall-penetration protocols for Tor in China2023-08-11T09:50:26ZcomputerscotModern firewall-penetration protocols for Tor in ChinaReports on https://github.com/net4people/bbs/issues and https://forum.torproject.org say that both obfs4 and snowflake are blocked by the GFW. There are also doubts about whether the new WebTunnel pluggable transport will work. The GFW d...Reports on https://github.com/net4people/bbs/issues and https://forum.torproject.org say that both obfs4 and snowflake are blocked by the GFW. There are also doubts about whether the new WebTunnel pluggable transport will work. The GFW detects and blocks WebSocket-based proxies.
This is a proof-of-concept for more modern firewall-penetration protocols.
To test these protocols in action, set up an Xray server and client using the latest techniques, for example, https://cscot.pages.dev/2023/07/02/xray-reality-h2. If you follow the sample configuration in that article, you will have a SOCKS5 proxy listening on port `10808` on your client.
Download and install the Tor Browser from https://www.torproject.org.
When you run the Tor Browser for the first time, click **Configure Connection**.
Scroll down and click the **Settings** button at the bottom to configure how you connect to the internet. Check **I use a proxy to connect to the Internet**. The type is **SOCKS5**, the address is `127.0.0.1`, and the port is `10808`. Click **OK**.
I have found it more reliable to click **Select a Built-In Bridge**. This should not be necessary, since the Xray server is already outside the GFW. Perhaps it helps because built-in bridges are faster than random entry nodes. Select **obfs4**. Click **Connect**.
Now you can test your connection by trying to reach a Tor-only site.
BBC News in simplified Chinese:
```
https://www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion/zhongwen/simp
```
DW News in simplified Chinese:
```
https://www.dwnewsgngmhlplxy6o2twtfgjnrnjxbegbwqx6wnotdhkzt562tszfid.onion/zh/?zhongwen=simp
```
New York Times in simplified Chinese:
```
https://cn.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion
```
![dw-onion-simplified-chinese](/uploads/37794d56098885a7979eb2230e140737/dw-onion-simplified-chinese.png)meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41825ESR115: do something with Quarantined Domains2023-10-05T12:41:58ZThorinESR115: do something with Quarantined Domains[1834825](https://bugzilla.mozilla.org/show_bug.cgi?id=1834825) Implement Quarantined Domains feature
The quarantined domains (QD) feature is designed to prevent add-ons from running on a set of domains (controlled with remote settings ...[1834825](https://bugzilla.mozilla.org/show_bug.cgi?id=1834825) Implement Quarantined Domains feature
The quarantined domains (QD) feature is designed to prevent add-ons from running on a set of domains (controlled with remote settings by Mozilla). This set of domains is quarantined for a variety of reasons including but not limited to security.
cc @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41846firefox-android esr 115 introduced new nimbus use: they need to be disabled2024-02-26T15:04:11ZDan Ballardfirefox-android esr 115 introduced new nimbus use: they need to be disabledwhile rebasing "de78f81daf1... Bug 40185: Use NimbusDisabled" it was discovered esr 115 had introduced new uses of Nimbus (such as in Settings.kt)
These all need disabling
- Settings.kt
- DefaultLocaleSettingsControler.ktwhile rebasing "de78f81daf1... Bug 40185: Use NimbusDisabled" it was discovered esr 115 had introduced new uses of Nimbus (such as in Settings.kt)
These all need disabling
- Settings.kt
- DefaultLocaleSettingsControler.ktDan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41911Firefox-Android tor bootstrap connect button css broken2023-10-03T13:28:49ZDan BallardFirefox-Android tor bootstrap connect button css brokenthe text lost its centering
![Screenshot_20230725-120325](/uploads/a74e35270a0d8b4bad31662a44f7e843/Screenshot_20230725-120325.png)the text lost its centering
![Screenshot_20230725-120325](/uploads/a74e35270a0d8b4bad31662a44f7e843/Screenshot_20230725-120325.png)Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41999TB13.0a2 android: center text on connect button2023-10-03T13:28:10ZThorinTB13.0a2 android: center text on connect buttonupdated from 12.5 series
- connect text on connect button is not centered
moved
- #42023 since I upgraded a version, I got a meatball bull dot for what's new -> firefox release page
- #42024 when I visited the first website, I got a Fir...updated from 12.5 series
- connect text on connect button is not centered
moved
- #42023 since I upgraded a version, I got a meatball bull dot for what's new -> firefox release page
- #42024 when I visited the first website, I got a Firefox popup/panel telling me all about ETPDan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41860Rebase 12.5 stable to 102.13esr2023-06-30T09:43:21ZPier Angelo VendrameRebase 12.5 stable to 102.13esr**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
- [x] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository):
- [x] Remove previous stable `base-browser` and `tor-browser` branch protection rules (this will prevent pushing new changes to the branches being rebased)
- [x] 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**
- [x] Find the Firefox mercurial tag here: https://hg.mozilla.org/releases/mozilla-esr102/tags
- **Example**: `FIREFOX_102_8_0esr_BUILD1`
- [x] 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`
- [x] Sign and Tag `gecko-dev` commit
- Sign/Tag `gecko-dev` commit :
- **Tag**: `$(ESR_TAG)`
- **Message**: `Hg tag $(ESR_TAG)`
- [x] 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`
- [x] 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`
- [x] Push new `base-browser` branch to `upstream`
- [x] Push new `tor-browser` branch to `upstream`
- [x] Push new `$(ESR_TAG)` to `upstream`
### **Rebase tor-browser**
- [x] 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`
- [x] `tor-browser` rebase
- [x] Note the current git hash of `HEAD` for `tor-browser` rebase+autosquash step: `git rev-parse HEAD`
- [x] 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`
- [x] Rebase and autosquash these newly cherry-picked commits: `git rebase --autosquash --interactive $(PREV_HEAD)`
- **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [x] 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`
- [x] 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`
- [x] Compare patch sets to ensure nothing *weird* happened during conflict resolution:
- [x] 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)
- [x] 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`
- [x] Open MR for the `tor-browser` rebase
- [x] Merge
- Update and push `base-browser` branch
- [x] Reset the new `base-browser` branch to the appropriate commit in this new `tor-browser` branch
- [x] Push these commits to `upstream`
### **Sign and Tag**
- [x] 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`
- [x] Push tag to `upstream`
- [x] 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`
- [x] Push tag to `upstream`Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41812Review layout for XUL elements2023-10-03T13:29:31ZhenryReview layout for XUL elements[mozilla bug 1033225](https://bugzilla.mozilla.org/show_bug.cgi?id=1033225) has been switching the XUL layout to use the standard CSS flex layout for elements with `-moz-box` styling.
This should clean up some weird XUL behaviour. E.g. ...[mozilla bug 1033225](https://bugzilla.mozilla.org/show_bug.cgi?id=1033225) has been switching the XUL layout to use the standard CSS flex layout for elements with `-moz-box` styling.
This should clean up some weird XUL behaviour. E.g. https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41371. But there may be some initial layout bugs as a result for ESR 115. E.g. the downloads panel used a `width: 0` hack to ensure it did not make the panel grow too wide, but with the new layout this makes it wrap every word.
This issue is to go through and check for these kind of layout bugs for the new ESR. But also try and remove some of the CSS hacks that were added for the XUL quirks.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41833Reload extensions on new identity2023-10-17T20:49:47Zma1Reload extensions on new identityNew Identity is perceived and advertised as a sort of "soft restart" which, among other things, resets all the linkable state.
However extensions don't get reloaded or even notified, therefore they've got no chance of resetting their st...New Identity is perceived and advertised as a sort of "soft restart" which, among other things, resets all the linkable state.
However extensions don't get reloaded or even notified, therefore they've got no chance of resetting their state as they should for this feature to be consistent when they're present.
/cc @pierov @ruihildtma1ma1https://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/41834Hide "Can't Be Removed - learn more" menu line for uninstallable add-ons2023-10-03T17:14:38ZThorinHide "Can't Be Removed - learn more" menu line for uninstallable add-onsthe link leads to [here](https://support.mozilla.org/en-US/kb/cannot-remove-add-on-extension-or-theme) on SUMO where it tells you how to delete the XPI
![learnmore](/uploads/b52317b6f6a00a167a57fead7ea305ac/learnmore.png)
We could do w...the link leads to [here](https://support.mozilla.org/en-US/kb/cannot-remove-add-on-extension-or-theme) on SUMO where it tells you how to delete the XPI
![learnmore](/uploads/b52317b6f6a00a167a57fead7ea305ac/learnmore.png)
We could do without this footgun cc @donuts @ma1ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41845Stop forcing (bad) pref values for non-PBM users2023-10-03T15:34:42ZPier Angelo VendrameStop forcing (bad) pref values for non-PBM users`torbutton.js` currently associates 4 preferences to having private browsing mode enabled by default:
- `browser.cache.disk.enable`: never use disk cache to avoid disk-leak. I think memory cached is still used for something, but I haven...`torbutton.js` currently associates 4 preferences to having private browsing mode enabled by default:
- `browser.cache.disk.enable`: never use disk cache to avoid disk-leak. I think memory cached is still used for something, but I haven't checked.
- `places.history.enabled`: history, set back to `true` to enable it when one disables PBM.
- Right now, in this way we force users that don't want PBM to have history on (which doesn't make sense, unless we want to give them a reminder of what they're doing?)
- I think it won't do anything in PBM anyway, so we could just unset any user value (once) and leave users do whatever they want.
- But I wonder if flipping this has some consequences, e.g., automatically delete history when you do it.
- Finally, this value is not defined in our profiles, currently, but we could set it to `false`, to have new users explicitly enable it if they don't want to use PBM (e.g., to keep logins).
- `security.nocertdb`: enable/disable user's certificate and key databases (set to `false` to use them).
- This is pretty easy, imho: they are a security threat also for non-PBM users, so we should restore it to `false` for everybody once, and then not change anymore (so people will have/will be able to change it manually, if they really want to).
- `permissions.memory_only`: use an in-memory database for permissions.
Before PBM, they were controlled by a checkbox. I wonder if they were a way to create PBM when PBM wasn't even a thing, yet.
However, right now they seem a UX nightmare to me.
They are not needed in PBM (also Arkenfox says they're optional), but our code **force** bad values for non-PBM (if I understand the code well, that happens whenever you open a new window!).
Non-PBM isn't supported by default, so I'd just switch to the values we set for PBM, and let users reset the non-safe values, if they really wish to do so.
We could even add a scary warning to `about:tor` to tell them that the behavior is changing.
Please notice that I don't want to lock these prefs, I just suggest to have good defaults, instead of forcing bad values.
/cc @donuts @thorinPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41821Fix the proxy type in the proxy modal of about:preferences in 13.02023-10-03T13:29:29ZPier Angelo VendrameFix the proxy type in the proxy modal of about:preferences in 13.0We will need to do some adjustment to our preferences page.
So far, I've found that the class to convert a checkbox into a switch has probably changed, and we should fix the proxy modal.
<details><summary>Screenshots</summary>
![Scree...We will need to do some adjustment to our preferences page.
So far, I've found that the class to convert a checkbox into a switch has probably changed, and we should fix the proxy modal.
<details><summary>Screenshots</summary>
![Screenshot_from_2023-06-08_15-58-52](/uploads/4df0759b3815be9e3e3724619004779b/Screenshot_from_2023-06-08_15-58-52.png)
![Screenshot_from_2023-06-08_16-00-21](/uploads/71fa320ed18c70c299db129ce3244aa3/Screenshot_from_2023-06-08_16-00-21.png)
</details>
EDIT: updated title to fix regression in the 13.0 serieshenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41823Investigate why system font hash has changed between 102 and 1152024-03-06T09:11:07ZPier Angelo VendrameInvestigate why system font hash has changed between 102 and 115It seems that TZP detects a change in system font hashes between 102 and 115.
We should investigate, to see what changed, and if everything is still okay.
/cc @thorinIt seems that TZP detects a change in system font hashes between 102 and 115.
We should investigate, to see what changed, and if everything is still okay.
/cc @thorinPier Angelo VendramePier Angelo Vendrame