Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2023-08-22T17:03:52Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41963builds: improve benchmarking2023-08-22T17:03:52ZThorinbuilds: improve benchmarkingspun off from #32759 ... so (windows) annecdata benchmarking indicates several things
**speedometer**
- TB/MB are consistently operating at around 2/3rds of ESR
- uBO affects perf at ~5%
- which is not an issue and is a symptom more ...spun off from #32759 ... so (windows) annecdata benchmarking indicates several things
**speedometer**
- TB/MB are consistently operating at around 2/3rds of ESR
- uBO affects perf at ~5%
- which is not an issue and is a symptom more about how the test is run than real-world? IDK
- uBO will be in TB at some stage, and the benefits (less network fetches etc) outweigh any cons IMO
- @pierov mentioned reproducible builds, PGO, LTO and I mentioned mingw - cc @fabrizio
- I will update jetstream and motionmark data after I test them
- needs labels and/or moving to appropriate repo cc @richard
**jetstream**
- about an 8% hit: is this primarily due to API/pref flips?
- NI (well, I have ideas, but not important) why gecko "regressed": TB10 vs ESR78 results are legit
**motionmark** (when I add them)
- sizes
- `1000x1000` = small screen | `1400x900` and `1400x1000` = medium screen
- will use medium screen across all tests
- since RFP is disabled
- IDK how that affects realworld results (e.g. non 60FPS hardware)
- results seems to fluxuate a lot between releases
- also IDK if this test is relevant: e.g. the perf hit in FF118 looks huge, but then read [1848050#c2](https://bugzilla.mozilla.org/show_bug.cgi?id=1848050#c2)
<details><summary>thorin's hardware</summary><p>
- OS: Windows 11 Pro 64-bit
- CPU: AMD K19 (x12)
- RAM: 32.0GB Dual-Channel DDR4 @ 1598MHz
- Motherboard: Gigabyte Technology Co. Ltd. B550M DS3H AC (AM4)
- Graphics: 4095MB NVIDIA GeForce RTX 3060 (ASUStek Computer Inc)
</p></details>
<details><summary>methods/notes</summary><p>
- https://browserbench.org/
- no extensions (e.g. uBO impacts at least speedometer by ~5+%)
- no RFP (to get accurate perf)
- new (+ sanitized) browser session for each test (S, J, M)
- speedometer: two runs each test (using `test again`, i.e in same tab), took least ± (standard deviation?)
- LW = librewolf, WF = waterfox, AF = arkenfox
- All FF's except Beta and Nightly are portable versions (portable versions use mozilla's binaries)
- EDIT: redid FF tests, using PB windows, vs TB/MB
</p></details>
<details><summary>TB/MB results</summary><p>
```
PB windows
S (2.1) J (2.1) M (1.2) medium screen
FF115 239 ± 4.5 156 953
ESR115mingw 184 ± 2.0 150
TB13.0a 155 ± 1.9 144 939
--- ---
TB 65% 92%
ESR102.14 181 ± 3.4 135 874
TB12.5.2 114 ± 1.3 114 605 (418 with RFP)
MB12.5.1 115 ± 1.9 117
MB12.5.1+uBO 106 ± 3.1 114
--- ---
TB/MB 63% 85%
MB+uBO 58% 85%
ESR91.13 158 ± 4.4 106
TB11.5.8 104 ± 2.4 98
--- ---
TB 66% 92%
ESR78.15 128 ± 3.5 124
TB10.5.10 91 ± 1.1 114
--- ---
TB 71% 92%
```
</p></details>
<details><summary>FF/fork/other results</summary><p>
```
non-PB windows
S (2.1) J (2.1) M (1.2) medium screen
Chrome 115 291 ± 5.4 239 1795
Edge 115 287 ± 3.2 237 1576
Opera 114 247 ± 3.7 230 1573
FF118 (N) 267 ± 3.9 175 1203 (bugzilla 1848050#c2)
FF117 (D) 272 ± 1.2 161 921
FF117 (B) 266 ± 4.7 163 990
FF116 244 ± 3.6 157 925
FF116 (AF) 239 ± 4.0 158 936
FF116 (LW) 181 ± 2.5 139 853 (762 with RFP)
--- ---
LW 74% 89%
FF115 240 ± 2.3 154 953
Mercury115 234 ± 1.8 152 1002
FF114 238 ± 3.0 152 901
FF113 218 ± 3.0 149 921
FF112 211 ± 2.5 148 1007
FF111 199 ± 2.0 141 1041
FF110 197 ± 2.3 140 984
FF109 194 ± 2.3 142 979
FF108 189 ± 2.1 137 906
FF107 183 ± 2.8 124 752
FF106 176 ± 2.2 124 770
FF105 181 ± 4.1 133 916
FF104 178 ± 5.1 121 621
FF103 179 ± 4.6 120 577
FF102 179 ± 2.9 129 761
FF102 (WF) 143 ± 2.9 123 566
--- ---
WF 80% n/a
---
OMG... LMFAO
WF Classic 90 ± 1.5 93 460
Basilisk 43 ± 1.2 66 396
Palemoon 37 ± 1.2 62 380
```
</p></details>https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41424Reduce disk activity by disabling some unnecessary tasks and telemetry2023-11-14T22:30:29Zcypherpunks1Reduce disk activity by disabling some unnecessary tasks and telemetryActivity stream needs to be disabled again. Telemetry tasks that cause disk activity should ideally be conditional. `toolkit.telemetry.enabled` is true on nightly builds, that should be locked to false to keep it consistent across all bu...Activity stream needs to be disabled again. Telemetry tasks that cause disk activity should ideally be conditional. `toolkit.telemetry.enabled` is true on nightly builds, that should be locked to false to keep it consistent across all builds. `webextensions.storage.sync.enabled` could be set to false to eliminate 3 files from the profile folder. These will reduce the noise while monitoring files and preferences and could improve the stability and performance of the browser.
~~https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/bd5c511fdb39f93fb614c2e16fcf3bfa4208c875 disables [LaterRun](https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/83c9f8b8b9b58b9a01a4111aa830aa544b46b7f2) which stores the profile creation time in `browser.laterrun.bookkeeping.profileCreationTime` and the number of times the browser has been opened since then in `browser.laterrun.bookkeeping.sessionCount`.~~Sponsor 131 - Phase 5 - Ongoing Maintenancecypherpunks1cypherpunks1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41399Update Mozilla's patch for Bug 1675054 to enable brotli encoding for HTTP oni...2023-10-19T12:48:42ZrichardUpdate Mozilla's patch for Bug 1675054 to enable brotli encoding for HTTP onions as wellSee https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41141#note_2847944
>>>
I think we they also be checking for .onion here ( similar to mixed content blocker https://searchfox.org/mozilla-central/source/dom/security...See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41141#note_2847944
>>>
I think we they also be checking for .onion here ( similar to mixed content blocker https://searchfox.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#263 ). The mozilla patch( https://hg.mozilla.org/mozilla-central/rev/fc09cf8d7c91 ) just enables brotli encoding for loopback/localhost domains in addition to HTTPS, not for all secure contexts (so http .onion is missing out)
>>>
@tom please let me know if I'm misunderstanding the referenced patch
We should uplift any fix fro this.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41397Re-enable tab unloading for private browsing tabs2023-01-05T16:17:30ZrichardRe-enable tab unloading for private browsing tabsThe tab unloading feature was disabled in Firefox because it caused forced restarts after updates ( https://bugzilla.mozilla.org/show_bug.cgi?id=1751366 ). We only updates after Tor Browser is restarted by the user, so we may not be affe...The tab unloading feature was disabled in Firefox because it caused forced restarts after updates ( https://bugzilla.mozilla.org/show_bug.cgi?id=1751366 ). We only updates after Tor Browser is restarted by the user, so we may not be affected by this bug and may benefit from the perf improvements when Tor Browser is under memory pressure.
In 12.5 alpha series we should try reverting this patch and enabling tab unloading and see if this breaks anything.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41392Update network.http.htp2.* settings as appropriate in 001-tor-browser.js for ...2023-05-31T18:44:10ZrichardUpdate network.http.htp2.* settings as appropriate in 001-tor-browser.js for better user experience.Following the fix for https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27128 we should spend some effort to fully understand and test how each of the http2 knobs work and interact with network conditions with higher-la...Following the fix for https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27128 we should spend some effort to fully understand and test how each of the http2 knobs work and interact with network conditions with higher-latency and slower speeds then perhaps expected by Mozilla engineers.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41348cherry-pick macOS OSSpinLock replacements2022-10-19T07:32:24Zrichardcherry-pick macOS OSSpinLock replacementsThis popped up todaY: https://hacks.mozilla.org/2022/10/improving-firefox-responsiveness-on-macos/
These patches landed in Firefox 103:
- [Bug 1670885: Replace deprecated OSSpinLock with os_unfair_lock](https://bugzilla.mozilla.org/sho...This popped up todaY: https://hacks.mozilla.org/2022/10/improving-firefox-responsiveness-on-macos/
These patches landed in Firefox 103:
- [Bug 1670885: Replace deprecated OSSpinLock with os_unfair_lock](https://bugzilla.mozilla.org/show_bug.cgi?id=1670885)
- **f56fb96281556e7eded0cbb884acf1531eb2049d** : Fix post-fork() handlers for PHC/LogAlloc to work on macOS using unfair locks
- **8f9904bb767433e84255b3bc2324d9aadcce3dc2** : Replace deprecated NSSpinLocks with os_unfair_locks in the memory allocator
- [Bug 1774458: Use undocumented, non-public adaptive spinlocks on macOS 10.15+, revert to user-space spinlocks on older versions](https://bugzilla.mozilla.org/show_bug.cgi?id=1774458)
- **7e8fda1a8bf1a7989a6f44735ff3c3a3d1a8bc46** : Use undocumented, non-public adaptive spinlocks on macOS 10.15+, revert to user-space spinlocks on older versions
and this in 106:
- [Bug 1784018: Remove deprecated OSSpinLocks](https://bugzilla.mozilla.org/show_bug.cgi?id=1784018)
- **44cbaf42485d18dad8864addef719c8f3707ad3f** : Remove deprecated OSSpinLocks
We should see if these apply cleanly and consider cherry-picking to alpha (esr102)Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33046Test ETP enabled in Tor Browser2020-06-27T14:32:06ZMatthew FinkelTest ETP enabled in Tor BrowserLast year I ran some experiments comparing the loading of pages with Enhanced Tracking Protection (ETP) disabled and then with it enabled. The results from these experiments were not statistically significant, but the preliminary results...Last year I ran some experiments comparing the loading of pages with Enhanced Tracking Protection (ETP) disabled and then with it enabled. The results from these experiments were not statistically significant, but the preliminary results showed that ETP noticeably reduces the best and average case timing, but the variance is still problematic.
On the bright side, this is a good starting point. From an email I sent:
```
I started measuring Tor Browser's
speed while loading various webpages. This was with the goal of
comparing Tor Browser with the measurements Mozilla made two years ago
[0] when they released Quantum (and compared Firefox and Chrome). It
uses benchmarks provided by Firefox's Javascript API (using the
Navigation Timing API).
It seems like Tracking Protection does has a noticable impact on
page-load time. I still have the feeling that investigating ad and
tracker blockers is a worthwhile initiative (especially if we want to
remain relevant). There are some interesting results that require
further analysis because I can't explain them right now.
In the future, it would be very helpful if we extended these
measurements by including tor controller events related to circuit
build and stream sentconnect/connected events. We should also run these
tests from different geographic areas (particularly locations with low
throughput connections).
My takeaway from this is if (ideally) pages should load with 6 seconds
(as was Mozilla's target [0]), then I believe this is achievable as the
other network improvements (correcting weighting, solving bottlenecks,
etc.) are rolled out. In addition, as usual, this will require some
advocacy for helping promote tor-friendly websites.
----
Mozilla's measurements used Selenium for automating the tests. Luckily,
Kushal already made a Tor Browser Selenium driver[1], so adapting
Mozilla's test[2] was relatively simple.
These measurements used a slightly non-standard Tor Browser
configuration. The Navigation Timing API is a fingerprinting vector, so
it is disabled by default. |privacy.resistFingerprinting| was disabled
for these tests. Similarly, NoScript's XSS protection required manual
input while pages loaded, so the XSS protection was disabled for these
tests.
Two sets of tests were run. The first test did not change any other Tor
Browser settings. The second test enabled Tracking Protection. Each test
loaded 20 webpages[3] (19 webpages in that file plus
http://newsweek.com/). The list of webpages is shuffled before each run,
and Tor Browser is restarted between each run.
[0]
https://hacks.mozilla.org/2017/11/comparing-browser-page-load-time-an-introduction-to-methodology/
[1] https://github.com/webfp/tor-browser-selenium
[2] https://github.com/onkeltom/browser_pageloadspeed
[3]
https://github.com/onkeltom/browser_pageloadspeed/blob/master/news.txt
[4] https://w3c.github.io/navigation-timing/#processing-model
```
legacy/trac#30939 is a consequence of this work.
I described in another email how the tests were run:
```
I pushed a branch page_load_timing on
https://github.com/sysrqb/tor-browser-selenium/
It requires the same setup configuration as described in the README. I
installed the dependencies with --user.
- pip install --user tbselenium
- pip install --user -r tor-browser-selenium/requirements-dev.txt
- Downloaded geckodriver from the Github repo
I didn't use xvfb (simply for convenience), so I ran the page-load test
directly with:
$ NO_XVFB=1 TBB_PATH=~/tor-browser_en-US/ py.test tor-browser-selenium/tbselenium/test/test_pageload.py
Change TBB_PATH and path/to/test_pageload.py, as needed. Don't be
surprised if the browser doesn't launch immediately (it take 5-10
seconds on slower computers).
And, in case you're not aware, tor-browser-selenium currently only works
on Linux (the README says Debian/Ubuntu and I successfully used it on
Fedora). You'll need a system tor installed, too (or at least an
instance of tor running already listening on port 9050). I'd like to add
support for letting Tor Browser bootstrap and control its own tor in the
future.
```
See legacy/trac#32976 for a better way we get geckodriver.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32759Review Tor Browser prefs for performance improvements2023-08-22T22:05:58ZGeorg KoppenReview Tor Browser prefs for performance improvementsWe should go over the Firefox prefs and review them for performance impact (inspired by legacy/trac#3978). We might have some knobs that allow us to get the user some perceived performance improvements without sacrificing all the other p...We should go over the Firefox prefs and review them for performance impact (inspired by legacy/trac#3978). We might have some knobs that allow us to get the user some perceived performance improvements without sacrificing all the other properties Tor Browser provides.Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31893Measure performance of update pings and update downloads in Tor Browser2022-07-08T18:04:41ZGeorg KoppenMeasure performance of update pings and update downloads in Tor BrowserTo get a better understanding of how Tor impacts speed of browsers we could start with measurements for update pings and update downloads in Tor Browser.
Apart from being a good idea in general it would help coming up with actual number...To get a better understanding of how Tor impacts speed of browsers we could start with measurements for update pings and update downloads in Tor Browser.
Apart from being a good idea in general it would help coming up with actual numbers for Mozilla's decision on how to integrate and use Tor in Firefoxhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31110Tor Browser is having sex with CPU on Safest security level2020-06-27T14:33:13ZcypherpunksTor Browser is having sex with CPU on Safest security levelWhen you're looking at https://github.com/sisbell/tor-android-service/commit/1513f8d2ccaf99fa9d7e8fe1ae00b1f535697030When you're looking at https://github.com/sisbell/tor-android-service/commit/1513f8d2ccaf99fa9d7e8fe1ae00b1f535697030https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30977Make it possible to measure Tor performance while doing Tor Browser updates/u...2023-01-05T17:34:11ZGeorg KoppenMake it possible to measure Tor performance while doing Tor Browser updates/update pingsWhile being at All Hands ekr had the idea that we could make it possible to measure Tor performance when doing update pings and downloading updates. The idea is _not_ to send the data somewhere, rather being able to measure the time the ...While being at All Hands ekr had the idea that we could make it possible to measure Tor performance when doing update pings and downloading updates. The idea is _not_ to send the data somewhere, rather being able to measure the time the ping/updates take if one wants to look at that. We could emit a log message with the time it took for those actions and whether errors occurred (that e.g. led to retrying the whole thing).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30939Use Firefox's Tracking Protection as a means for performance improvements2023-03-03T08:48:30ZGeorg KoppenUse Firefox's Tracking Protection as a means for performance improvementsWhen improving browser performance one of the low-hanging fruits we could think about is using at least some of the Enhanced Tracking Protection (ETP) feature for that purpose. This ticket is the parent ticket to track all the involved w...When improving browser performance one of the low-hanging fruits we could think about is using at least some of the Enhanced Tracking Protection (ETP) feature for that purpose. This ticket is the parent ticket to track all the involved work.
There are a number of questions involved that we need to discuss and decide how to proceed (and probably more than I came up with below):
a) Do we want to use the same message and UI of ETP as it is shipped right now in Firefox?
b) Do we want to enable the same lists as Mozilla is doing in the respective browsing modes?
c) Do we want to use the same list retrieval mechanism as Mozilla (using the safebrowsing protocol)?
d) Do we want to host the tracking protection lists ourselves?
e) Does the work in this ticket (and child tickets) is our answer to "ship an ad blocker" in Tor Browser? Or do we feel the need to still ship another blocking tool on top of ETP?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27614Check TCP FastOpen for potential proxy bypass2021-03-23T21:18:03ZGeorg KoppenCheck TCP FastOpen for potential proxy bypassIn https://bugzilla.mozilla.org/show_bug.cgi?id=1188435 (and child bugs) support for TCP FastOpen got implemented. It got disabled on the release track in https://bugzilla.mozilla.org/show_bug.cgi?id=1431738. We should double-check wheth...In https://bugzilla.mozilla.org/show_bug.cgi?id=1188435 (and child bugs) support for TCP FastOpen got implemented. It got disabled on the release track in https://bugzilla.mozilla.org/show_bug.cgi?id=1431738. We should double-check whether we find any proxy bypass issues once this gets enabled.Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27476Remove gap between Tor Launcher window and main browser window2022-01-13T17:21:21ZArthur EdelsteinRemove gap between Tor Launcher window and main browser windowRight now, the Tor Launcher runs, and takes seconds or minutes to complete. The Tor Launcher window, though it says "Tor Browser" on the first screen is not recognizably a web browser, which may be confusing or scary to first-time users....Right now, the Tor Launcher runs, and takes seconds or minutes to complete. The Tor Launcher window, though it says "Tor Browser" on the first screen is not recognizably a web browser, which may be confusing or scary to first-time users.
Then the Tor Launcher window disappears, and then, before a browser window appears, there is a gap of varying length where no window is visible at all. On slow computers, this gap can be as much as tens of seconds and during that time there is no easy way to tell that Tor Browser is still running.
Often users, mistakenly guessing that Tor Browser has crashed, will double-click the Tor Browser app icon a second time and get messages like "Tor Browser is already running, but is not responding" or "Tor unexpectedly exited".
How can we solve this problem? I can think of a few possible solutions:
1. Don't hide the Tor Launcher window until the main browser window is visible. (Build the browser window hidden during the launch process so that it can appear fast as soon as the launch process is done.)
2. Show the main browser window below the Tor Launcher window while it launching process is running. Keep the Tor Launcher window modal (always on top) until it is finished.
3. Embed the Tor Launcher UI in the main browser window. Allow the user to enter a URL in the URL bar even before Tor is fully launched.
I favor (3) as having the best UX. But it is also the most difficult to implement.Sponsor 30 - Objective 3.3richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27196TB 8a10 and panopticlick: your browser has a unique fingerprint2022-01-11T19:31:57ZtraumschuleTB 8a10 and panopticlick: your browser has a unique fingerprintThe bundle works fine, thanks for your great work!
I am surprised by the new yellow blinking triangle over the onion settings button. What does it mean? (The tooltip only says "Tor Enabled")
= Update NoScript to 10.1.8.16
In NoScript p...The bundle works fine, thanks for your great work!
I am surprised by the new yellow blinking triangle over the onion settings button. What does it mean? (The tooltip only says "Tor Enabled")
= Update NoScript to 10.1.8.16
In NoScript preferences the list of per-site definitions was empty, I added a site and clicked on reset: a lot of whitelisted domains appeared (legacy/trac#26517).
= Trackers
As discussed before (legacy/trac#12958), [blocking content allows fingerprinting](https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Support_discuss#CanIinstallanewadd-onorextensioninTorBrowserlikeAdBlockPlusoruBlockOrigin), instead [[comment:4:ticket:12958|you suggest]] "an identical blocklist for every user. For example, AdBlock Plus with a fixed set of filters." Do you have plans to do this? (I am aware of your answers for [[comment:1:ticket:15279|uMatrix]] and [[comment:54:ticket:17569|ublock origin]] and spare you to repost everything :)
(mentioning [Riseup's recommendations](https://riseup.net/en/security/network-security/better-web-browsing) + requestblock for a balanced perspective, because I do not follow the conclusion that external requests should be accepted just not to be finger-printable. For me personally it's worse, when trackers know that I visited a site.)
legacy/trac#14924 sounds reasonable.
= EFF/Panopticlick
wants me to install privacybadger (not voting for it here, because of legacy/trac#12958)
Is your browser blocking tracking ads? ⚠ partial protection
Is your browser blocking invisible trackers? ⚠ partial protection
Does your blocker stop trackers that are included in the so-called “acceptable ads” whitelist? ✗ no
Does your browser unblock 3rd parties that promise to honor Do Not Track? ✗ no
Does your browser protect from fingerprinting? ✗
your browser has a unique fingerprint
https://share.riseup.net/#3RwdPLNSuFFZcK9MA_6l8g
I consider the defaults dangerous ([[comment:3:ticket:25451|window size]]). Why not setting the security slider to "Safest" per default?Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27127Audit and enable HTTP/2 push2022-10-25T21:26:34ZArthur EdelsteinAudit and enable HTTP/2 pushIn #14952 we plan to enable HTTP/2, but we are postponing enabling HTTP/2 push in case there are potential privacy concerns. Let's investigate any concerns here and hopefully enable push in the future.In #14952 we plan to enable HTTP/2, but we are postponing enabling HTTP/2 push in case there are potential privacy concerns. Let's investigate any concerns here and hopefully enable push in the future.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25735Tor Browser stalls while loading Facebook login page (Waiting for static.xx.f...2020-06-27T14:36:07ZTracTor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)Problem:
After opening the Tor Browser and typing in facebook.com, page loading hangs, status bar showing "Waiting for static.xx.fbcdn.net"
HTTP GET requests for small images from static.xx.fbcdn.net stall in the "Blocked" state for mi...Problem:
After opening the Tor Browser and typing in facebook.com, page loading hangs, status bar showing "Waiting for static.xx.fbcdn.net"
HTTP GET requests for small images from static.xx.fbcdn.net stall in the "Blocked" state for minutes - viewed in Developer tools / Network / request / Timing (see attached screenshot Step2.png).
When a different website is opened in a new tab, HTTP requests continue loading successfully - seems to be some livelock within the browser.
This is **not a network issue**, connectivity in the browser works fine, also verifed without a SOCKS proxy (direct connection without Tor).
Reproducibility: nearly 100%
Environment:
- Windows 10 Pro, 64bit
- Tor Browser 7.5.3 for Windows, english
- Tor Browser 8.0a5 for Windows, english
**Trac**:
**Username**: uzihttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25555Reimplement Optimistic SOCKS feature2024-02-27T10:54:54ZGeorg KoppenReimplement Optimistic SOCKS featureWe had to rip out the Optimistic SOCKS feature to get Moat working in Tor Browser (see: legacy/trac#24432) but we want it back for performance reasonsWe had to rip out the Optimistic SOCKS feature to get Moat working in Tor Browser (see: legacy/trac#24432) but we want it back for performance reasonshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24698Torbrowser keeps hanging and freezing, plus it takes a very long time to load...2022-02-03T19:06:05ZTracTorbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernationUsing Windows 7, 64-bit
I've had these same problems on two different laptops, both running Windows 7, 64-bit.
The past several versions of Torbrowser, including the recent 7.0.11 and 7.5a.9, the browser keeps hanging up and freezing....Using Windows 7, 64-bit
I've had these same problems on two different laptops, both running Windows 7, 64-bit.
The past several versions of Torbrowser, including the recent 7.0.11 and 7.5a.9, the browser keeps hanging up and freezing.
When the tabs are frozen, sometimes I can ctrl+tab to the next one, but the screen will be white and the address in the bar doesn't change, so it's not really changing tabs even though the highlighted tab changes.
Also, sometimes the window will additionally be on top of everything else when it's not supposed to be and I can't view any other windows. It won't restore to NOT being in front of every other program, and with it being frozen or hanging I will have to close it and start all over.
Additionally, when it does work it takes a very long time to load from hibernation to get to a point where the tabs function properly, sometimes as much as 20 minutes (with approx 15 open tabs, and that's really not many).
I will often have several tabs open and need to hibernate the computer to finish later. These problems typically occur after returning from hibernating. This keeps costing me hours of lost work.
I have tried reporting these issues several times before but have apparently not been in the right place so I hope this is the correct location to report these bugs so it can be fixed.
Thanks very much.
**Trac**:
**Username**: justmeeehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23770Unusually high CPU and memory usage for process plugin-countainer2020-06-27T14:36:51ZcypherpunksUnusually high CPU and memory usage for process plugin-countainerThis only seems to have appeared in these last days, plugin-countainer uses up to 270 Mb and at times has CPU usage that spikes to 30-40%.
Linux 64bits. Tor Browser 7.5a5, all addons are up-to-date (NS 5.1.1., HE 2017.10.4).This only seems to have appeared in these last days, plugin-countainer uses up to 270 Mb and at times has CPU usage that spikes to 30-40%.
Linux 64bits. Tor Browser 7.5a5, all addons are up-to-date (NS 5.1.1., HE 2017.10.4).