Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2023-09-29T06:40:27Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41819Stop providing our brand.dtd after we update the about dialog2023-09-29T06:40:27ZPier Angelo VendrameStop providing our brand.dtd after we update the about dialogIt isn't used anymore upstream: 1662ea09fa2589c689cc4e4189f6853546fd0685.
We still use it on `aboutDialog.dtd`.
We could move it there, but I think it'd be new strings to translate, so not very good, since we want to go away from legac...It isn't used anymore upstream: 1662ea09fa2589c689cc4e4189f6853546fd0685.
We still use it on `aboutDialog.dtd`.
We could move it there, but I think it'd be new strings to translate, so not very good, since we want to go away from legacy formats anyway.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41787Purple tor buttons use white text in both light and dark theme2023-10-11T21:38:25ZhenryPurple tor buttons use white text in both light and dark themeCurrent both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab....Current both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41608#note_2895231:
> in the figma mockups the "Connect" button uses almost-white text with a light theme, and almost-black text with a dark theme.
>
> In contrast the ".onion available" urlbar button always uses white text, regardless of theme:
>
> ![onion available button in dark mode](https://gitlab.torproject.org/tpo/applications/tor-browser/uploads/dac4112fc2b8aa6d21c65bb76cda4e25/onion-available-dark-mode.png)
And the reply from @donuts
> The two variants are supposed to use `purple-60` (light theme) and `purple-30` (dark theme) for backgrounds, and the normal label color for foregrounds (e.g. page-color, I think?).
>
> For consistency, maybe we should ignore the dark theme variant for now, and we can open a separate issue to fix this everywhere (i.e. torconnect, onion-location, and this instance).henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41772Bridge stacks for built-in bridges are confusing users2024-02-20T09:42:42ZdonutsBridge stacks for built-in bridges are confusing usersAt present, built-in obfs4 includes 11 bridges and Snowflake includes 2, each of which generates a corresponding number of bridge cards in Connection Settings' UI.
For most use-cases, being able to view and prune the full stack makes mo...At present, built-in obfs4 includes 11 bridges and Snowflake includes 2, each of which generates a corresponding number of bridge cards in Connection Settings' UI.
For most use-cases, being able to view and prune the full stack makes more sense for bridges that have been requested through moat or added manually. Conversely, users are confused as to why they're seeing so many bridges after selected a built-in bridge, and we may want to explore custom bridge cards for built-in bridges that don't reveal the individual bridge lines instead.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41758ESR115: android: don't allow PDFs to be opened by 3rd party apps2023-08-26T05:12:29ZThorinESR115: android: don't allow PDFs to be opened by 3rd party appshttps://bugzilla.mozilla.org/show_bug.cgi?id=1829372 - landed in FF114https://bugzilla.mozilla.org/show_bug.cgi?id=1829372 - landed in FF114https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41719Update title and button strings in the new circuit display to sentence case2023-04-17T20:32:23ZdonutsUpdate title and button strings in the new circuit display to sentence caseIt looks like the browser chrome is already mostly sentence case (qith the exception of the ETP panel, which we have disabled anyway), so I think we should go ahead and sentence-case-ify the new circuit display straight away.
- `Tor Cir...It looks like the browser chrome is already mostly sentence case (qith the exception of the ETP panel, which we have disabled anyway), so I think we should go ahead and sentence-case-ify the new circuit display straight away.
- `Tor Circuit` → `Tor circuit`
- `Guard` → `guard`
- `New Circuit for this Site` → `New circuit for this site`
^ We actually use `New Tor circuit for this site` in the application menu already, so we could switch the circuit display to use that string instead for consistency.
Not sure if there are any more strings lurking there.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41717Bookmark toolbar visibility on new tabs is not honored when new tab page is n...2023-10-05T20:20:33ZFabrizioBookmark toolbar visibility on new tabs is not honored when new tab page is not about:blank**STR**:
1. Right click on the bookmark toolbar.
2. Make sure its visibility is set to "Only show on New Tab".
3. Open a new tab.
**Result**:
If you check about:config,`browser.toolbars.bookmarks.visibility` is flipped but the toolbar...**STR**:
1. Right click on the bookmark toolbar.
2. Make sure its visibility is set to "Only show on New Tab".
3. Open a new tab.
**Result**:
If you check about:config,`browser.toolbars.bookmarks.visibility` is flipped but the toolbar is not visible.
**Notes**:
- Also affecting Mullvad Browser: https://github.com/mullvad/mullvad-browser/issues/14.
- @thorin says Windows is working just fine. I can test Linux later today, if needed.
- IMO it makes sense to have `browser.toolbars.bookmarks.visibility` set to `never` whenever letterboxing is enabled.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41716Figure out how to display conflux circuits in Tor Browser's UI2024-01-29T19:26:13Zmicahmicah@torproject.orgFigure out how to display conflux circuits in Tor Browser's UINow that circuit display was literally just re-implemented...
When 0.4.8 becomes stabilized (this will take a few months still), conflux will come to the network. Conflux will open a new world with tor circuits: circuits are no longer n...Now that circuit display was literally just re-implemented...
When 0.4.8 becomes stabilized (this will take a few months still), conflux will come to the network. Conflux will open a new world with tor circuits: circuits are no longer necessarily static, now they can be dynamic, the TCP circuits can change paths, and can have multiple paths, and doing so can bring some nice improvements for people.
We need to start thinking about how we want to communicate to the user in TB. Specifically that the circuit(s) are conflux circuits. Users knowing that they are using a conflux circuit will provide valuable information to them (and their feedback to us as well).
Because the circuits can now change paths, this could have a lot of UI visualization implications, such as reflecting that there are these paths that are now ready, or that there is a new circuit leg available. That would be the nice (but complicated) signal to users, but starting with something simple by just indicating in the UI that this is a conflux circuit (eg. literally just writing the word 'conflux' in green or something) would be a good first signal step. So there is a UX question here.
For the dev side of things, right now its possible (in 0.4.8) to get from the control port that a circuit is a conflux circuit, but it doesn't have any advanced information that would be useful for multi-leg displays, but if we want to show those types of things, we will need to talk about what would be needed to be added to tor to extract that information.
perhaps we can have a ad-hoc session at our in-person meeting to brief folks on what conflux means and its benefits.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41679Backport Android-specific security fixes from Firefox 111 to ESR 102.9-based ...2023-04-10T16:09:57ZrichardBackport Android-specific security fixes from Firefox 111 to ESR 102.9-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 defin...<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`
- `$(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` rebase has already happened and there exists a `build1` build tag for both `base-browser` and `tor-browser`
### **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) 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` : https://github.com/mozilla-mobile/firefox-android
- `fenix` : 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.
- [x] Go through any `Security Vulnerabilities fixed in Firefox $(RR_VERSION)` (or similar) 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
- [x] 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 a link 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.
### **tor-browser** : https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [x] Backport any Android-specific security fixes from Firefox rapid-release
- [x] Sign/Tag commit:
- Tag : `tor-browser-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha)`
- [x] Push tag to `origin`
**OR**
- [ ] No backports
### **application-services** : *TODO: we will need to setup a gitlab copy of this repo that we can apply security backports to if there are ever any security issues here*
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Sign/Tag commit:
- Tag : `application-services-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha`
- [ ] Push tag to `origin`
**OR**
- [x] No backports
### **android-components** : https://gitlab.torproject.org/tpo/applications/android-components.git
- [x] 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.
- [ ] Sign/Tag commit:
- Tag : `android-components-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha)`
- [ ] Push tag to `origin`
**OR**
- [ ] No backports
### **fenix** : 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.
- [ ] Sign/Tag commit:
- Tag : `tor-browser-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha)`
- [ ] Push tag to `origin`
**OR**
- [x] No backports
### CVEs
- [ ] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-28159
- https://bugzilla.mozilla.org/show_bug.cgi?id=1783561
- **patches**:
- android-components: https://github.com/mozilla-mobile/firefox-android/pull/565/commits
- fenix: https://github.com/mozilla-mobile/fenix/pull/28572/commits
- [ ] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-25748
- https://bugzilla.mozilla.org/show_bug.cgi?id=1798798
- **patch**: https://github.com/mozilla-mobile/firefox-android/commit/1dc21a3786506200be124733e654dff8f39b5395
- [x] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-25749
- https://bugzilla.mozilla.org/show_bug.cgi?id=1810705
- **patch**: https://github.com/mozilla-mobile/firefox-android/commit/4ff195aa268af1dabbcac050bb6e3e6e9abecff7
- **note**: our existing fix for fenix#34378 actually fixes this already so let's not backport this one :D
- [x] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-25750
- https://bugzilla.mozilla.org/show_bug.cgi?id=1814733
- esr102 unaffected AND this is a service workers issue (service workers are not enabled in Tor Browser)
- [x] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-28160
- https://bugzilla.mozilla.org/show_bug.cgi?id=1802385
- **patch**: https://hg.mozilla.org/mozilla-central/rev/554a5aa89673
- **note:** This is a potential fingerprinting vector fix, but only accessible from webextensions which Android in general doesn't support very many of so if this is a pain to backport that's fine
- [x] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-28161
- https://bugzilla.mozilla.org/show_bug.cgi?id=1811181
- This patch would apparently require a lot of re-work for esr102 (and is not applicable to Android) so lets skip it
- [x] https://www.mozilla.org/en-US/security/advisories/mfsa2023-09/#CVE-2023-28177
- [x] https://bugzilla.mozilla.org/show_bug.cgi?id=1817336
- esr102 unaffected, affects linux desktop
- [x] https://bugzilla.mozilla.org/show_bug.cgi?id=1803109
- only happens when profiling which is one reason they didn't backport
- **patch**: https://hg.mozilla.org/mozilla-central/rev/adcb31b93a01
- [x] https://bugzilla.mozilla.org/show_bug.cgi?id=1809542
- esr102 unaffected, affects Windows
- [x] https://bugzilla.mozilla.org/show_bug.cgi?id=1808832
- esr102 unaffected,
<!-- Create CVE resolution here -->ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41655Text in the Try Onion Services popup could be clearer2024-03-13T17:04:49ZhenryText in the Try Onion Services popup could be clearerI feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So...I feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So it seems like it should be more like "Use Onion Services".
## Body
The first sentence is
> There is a more private and secure version of this site available over the Tor network via onion services.
Given the context of this being shown when you visit a HTTPS site, this seems to be telling the user that the current connection they have to the HTTPS site is less private and less secure than if they used the onion site. Moreover, there is no text in the "Learn more" link (https://tb-manual.torproject.org/onion-services/) to back this up. It only says
> All traffic between Tor users and onion services is end-to-end encrypted, so you do not need to worry about connecting over HTTPS
but we already have HTTPS-Only mode in the browser.
In contrast, the second sentence
> Onion services help website publishers and their visitors defeat surveillance and censorship.
is easily understood and backed up.
I feel like maybe this first sentence should be more of a light overview of what an onion service *is*, with the second sentence being the benefits, making it clear what is benefiting the tor browser user.
## Button label
At least for me, "Not Now" tends to mean "I will bother you again in the future until you select the other option", so it can imply the *popup* will shown again for the next onion-available site, even though the user will never see it again. I think this is *trying* to indicate that you can always set this preference in the "Privacy & Security" settings in the future, but that could just be part of the body text if it is important.
## Design estimate:
* Complexity: low (1 days)
* Think about:
* How would a new user understand this? Do a mini user journey.
* What are the different ways the copy / design can be misunderstood?
* Ask:
* What is this thing?
* How does it benefit me?
* What are you asking me to do?
* Uncertainty level: high (2)
* I don't do much copy, so it's a bit of a challenge for me.
* There could be lenghty back and forth between stakeholders discussing the copy.
* Total: 1-2 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41644fonts linux: test whitelist breakage2023-04-17T15:03:19ZThorinfonts linux: test whitelist breakagenot an issue, but a Q for @pierov
In my much awaited but not yet deployed new fang-dangled snazzy TZP (30% smaller, 30% faster, with MOAR metrics), I am not just collecting font enumeration and sizes, but now also checking that any whi...not an issue, but a Q for @pierov
In my much awaited but not yet deployed new fang-dangled snazzy TZP (30% smaller, 30% faster, with MOAR metrics), I am not just collecting font enumeration and sizes, but now also checking that any whitelist (or RFP's font vis) doesn't leak (as well as for missing bundled fonts in TB). But there is no need to check massive lists in TB, as most fonts are bundled: this would just adds lots of perf overhead
<details><summary>sample code</summary><p>
lists are snipped for brevity where stated
```js
let fntMaster = {
// TB bundled
"bundled": {
"all": [ // 118 win/mac/linux
"Noto Sans Adlam","Noto Sans Balinese", // SNIP
],
"android": [],
"linux": [ // +16
"Arimo","Cousine", // SNIP
],
"mac": [ // +5
"Noto Sans Armenian","Noto Sans Hebrew", // SNIP
],
"windows": [ // +4
"Noto Naskh Arabic", // SNIP
],
},
// TB whitelist
"allowlist": {
"android": [],
"linux": [],
"mac": [
"AppleGothic","Apple Color Emoji", // SNIP
],
"windows": [
"Arial","Cambria Math" // SNIP
],
},
// TB unexpected: to catch failures
"blocklist": {
"android": [],
"linux": [
'Arial','Courier','Courier New','Noto Emoji','Noto Sans','Noto Serif',
'Noto Color Emoji','Noto Mono','Cantarell','DejaVu Sans','DejaVu Serif',
'Droid Sans','STIX','Symbola','Dingbats','FreeMono','Ubuntu',
],
"mac": ["Apple Symbols","Avenir","Charter","Impact","Palatino","Rockwell",],
"windows": ["Calibri","Candara","Corbel","Impact","Ebrima","Gabriola",],
},
```
</p></details>
so we end up with something like this, where the green `[TB]` notation means no bundled fonts were missing _AND_ we didn't leak anything outside the whitelist (I call it an allowlist on the page so as to not be offensive). The bundled list (122) is a subset of allowed (155), which is a subset of the fonts tested (162 - which includes a fake random font as a poison pill)
![example](/uploads/3f3c8ffbbc960747ea70a90a8797b08b/example.png)
Now windows/mac is simple - I can add expected system fonts since win7/macOS10.12 to the "blocklist" and if they are detected then the whitelist is failing.
But linux is trickier. My initial "blocklist"ed items are, I think fairly common, especially on ubuntu and fedora, but I am not super linux font savvy. Can you improve on this list (without going massive on it: smaller is better) - see code examplehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41642Do not hide new PBM in the hamburger menu if auto PBM is not enabled2023-10-03T15:37:43ZPier Angelo VendrameDo not hide new PBM in the hamburger menu if auto PBM is not enabledImprovement for 2a6e497977d8ab4996d8a1c77dbdcb1ae60eb486.Improvement for 2a6e497977d8ab4996d8a1c77dbdcb1ae60eb486.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41634Google Play incorrectly detects that libTor.so is built with OpenSSL 1.1.1b2023-08-17T20:53:33ZrichardGoogle Play incorrectly detects that libTor.so is built with OpenSSL 1.1.1bRelated: https://gitlab.torproject.org/tpo/core/tor/-/issues/40759
We can try to patch out the offending string from the tor source for now.Related: https://gitlab.torproject.org/tpo/core/tor/-/issues/40759
We can try to patch out the offending string from the tor source for now.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41620Improve the UX of the request a bridge dialog2024-03-05T18:48:23ZdonutsImprove the UX of the request a bridge dialogFollowing recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), w...Following recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), we should also take a look at improving the UX of the request a bridge dialog. However it makes sense to wait on the outcome of https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/49 first, where the Anti-Censorship team will be considering a new CAPTCHA strategy.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41602Designing the User Interface of Conjure in Tor Browser2023-05-30T21:43:51ZrichardDesigning the User Interface of Conjure in Tor BrowserFollowing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41361 we need to do the UX work for exposing this feature to users.
@cohosh can you reply with a blurb about how conjure works/differs from other bridges, tra...Following https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41361 we need to do the UX work for exposing this feature to users.
@cohosh can you reply with a blurb about how conjure works/differs from other bridges, tradeoffs, etc so we get a string written for the bridge selection UX ( see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41583#note_2870062 for reference).Sponsor 30 - Objective 2.3https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41582Tor Browser Android app context menu still has option to open "New Tab" (not ...2023-08-26T06:09:43ZDan BallardTor Browser Android app context menu still has option to open "New Tab" (not private). Crashes when invokedTor Browser Android app has a context menu item on the app on home screen's for "New Tab" (the non private version). This should not appear. Semi thankfully, when invoked, tor browser seems to crash and restart.
This menu item should be...Tor Browser Android app has a context menu item on the app on home screen's for "New Tab" (the non private version). This should not appear. Semi thankfully, when invoked, tor browser seems to crash and restart.
This menu item should be removedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41580Download an external file type popup isn't assigned to the Tor Browser2023-08-22T20:54:51ZPorkepixDownload an external file type popup isn't assigned to the Tor Browser<!--
* Use this issue template for reporting a new UX bug.
-->
### Summary
The "Download an external file type" popup is assigned to the classic Firefox program in Gnome if it's opened besides the Tor Browser.
### Steps to reproduce:
...<!--
* Use this issue template for reporting a new UX bug.
-->
### Summary
The "Download an external file type" popup is assigned to the classic Firefox program in Gnome if it's opened besides the Tor Browser.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. From a computer with a recent Gnome, download a file with the Tor Browser that would trigger the "Download an external filetype" popup, while having a standard Firefox opened
2. When the popup triggers (which can be delayed from the moment user click on the button in some rare cases such as the usage of local storage and unencryption after), this popup will be assigned to the Firefox icon/program when alt-tabbing rather than the Tor-Browser one.
3. I believe that despite being a Firefox process, the Tor Browser had things modified to don't be grouped up with a classic Firefox, maybe this popup needs the same treatment?
### What is the current bug behavior?
The popup visible below is assigned to the Firefox program rather than the Tor Browser's one.
### What is the expected behavior?
It should correctly be assigned to Tor Browser instead.
## Relevant logs and/or screenshots
![Screenshot_from_2023-01-16_20-10-36](/uploads/76a195a70454ac8bf9edd2267b468272/Screenshot_from_2023-01-16_20-10-36.png)
I don't know what would happen if Firefox wasn't opened, I didn't have the case up to now (and it's unlikely to happen as my Firefox is always opened).
EDIT: Gnome don't let me take a screenshot while I hold the alt button, so I can't really show the problem during the alt-tab.
Also, on this popup, shouldn't there be an icon on the left of the text instead of this little question mark?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41572Check for userContextId also in the circuit display2023-02-01T15:02:49ZPier Angelo VendrameCheck for userContextId also in the circuit displayThe changes of !494 need also some changes on the circuit display side.
At the moment, it's broken because it cannot find the credentials anymore.The changes of !494 need also some changes on the circuit display side.
At the moment, it's broken because it cannot find the credentials anymore.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41568Disable LaterRun2023-02-15T18:05:45Zcypherpunks1Disable LaterRunDetails: https://bugzilla.mozilla.org/show_bug.cgi?id=1200639
The feature is controlled by `browser.laterrun.enabled`.
It stores the profile creation time in `browser.laterrun.bookkeeping.profileCreationTime`.
It stores the number of ...Details: https://bugzilla.mozilla.org/show_bug.cgi?id=1200639
The feature is controlled by `browser.laterrun.enabled`.
It stores the profile creation time in `browser.laterrun.bookkeeping.profileCreationTime`.
It stores the number of times the browser has been used in `browser.laterrun.bookkeeping.sessionCount`.cypherpunks1cypherpunks1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41566Migrate maximizing warning panel out of torbutton to base-browser2023-07-28T13:04:27ZrichardMigrate maximizing warning panel out of torbutton to base-browserMigrate this functionality to a separate patch that lives somewhere near the letterboxing improvement patches in the base-browser section.Migrate this functionality to a separate patch that lives somewhere near the letterboxing improvement patches in the base-browser section.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41560Turning letterboxing off results in newtab not rendering2023-01-30T08:35:42ZThorinTurning letterboxing off results in newtab not renderingSTR (using latest alpha)
- TB not connected
- flip LB off
- in a new tab load a file:// scheme
- nothing shows
- toggle LB on, change to test tab, it shows
- now you can use that tab regardless of the LB pref, but new tabs will exhibit t...STR (using latest alpha)
- TB not connected
- flip LB off
- in a new tab load a file:// scheme
- nothing shows
- toggle LB on, change to test tab, it shows
- now you can use that tab regardless of the LB pref, but new tabs will exhibit the issue
Related to newtab window "clamping" _I think_ - I'll let you debug it = @ma1
<details><summary>behold my mighty gif making skills</summary><p>
![filescheme](/uploads/f36de91e40f5ae90a4d647e0091b3bd3/filescheme.gif)
</p></details>ma1ma1