Skip to content
Snippets Groups Projects
New look: Off

Tor-browser downloads favicon twice (and over different circuits) on Windows

    • Closed (moved) Issue created by cypherpunks @cypherpunks

    When opening an image directly inside Tor-browser it ends up being downloaded twice. Two HTTP GET requests get sent to the server.

    The issue comes from the icon shown on the tabbar: If I disable browser.chrome.favicons and browser.chrome.site_icons then the double download does not happen.

    Can this be prevented by for instance loading the tab icon from the cache?

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • cypherpunks added component::applications/tor browser ff45-esr-will-have owner::tbb-team priority::medium resolution::fixed severity::major status::closed tbb-linkability type::defect labels

      added component::applications/tor browser ff45-esr-will-have owner::tbb-team priority::medium resolution::fixed severity::major status::closed tbb-linkability type::defect labels

    • Georg Koppen
      Georg Koppen @gk ·

      Hmm... which Tor Browser are you testing this with? Do you have an example URL where this is happening? I just used the 5.0 candidate and I only see one download for e.g. https://s3.amazonaws.com/disconnect-images/images/search/get-premium-protection-home.png.

      Trac:
      Status: new to needs_information

    • C
      cypherpunks @cypherpunks ·
      Author

      This is on version 4.5.3. It is also only noticeable on the server logs: in the browser itself you can only see one request (in the console or network tab). I don't have an example url handy, but could simulate it with python's builtin http server (python -m http.server) and using a service like ngrok.com to make the server accessible publicly.

      I tried doing this on the 5.0 version and there the download does not happen twice, so it looks like this is already solved.

    • Georg Koppen
      Georg Koppen @gk ·

      Ah, okay. Thanks for testing.

      Trac:
      Status: needs_information to closed
      Resolution: N/A to worksforme

    • C
      cypherpunks @cypherpunks ·
      Author

      This is still an issue with TB 5.5a3. Single request for / with embedded image from my httpd logs:

      • $exitIP1 - "GET / HTTP/1.1" 200 "-" "Mozilla/5.0 (Windows NT 6.1; !rv:38.0) Gecko/20100101 Firefox/38.0"

      • $exitIP1 - "GET /content.gif HTTP/1.1" 200 "!http://domain.tld/" "Mozilla/5.0 (Windows NT 6.1; !rv:38.0) Gecko/20100101 Firefox/38.0"

      • $exitIP2 - "GET /favicon.ico HTTP/1.1" 200 "-" "Mozilla/5.0 (Windows NT 6.1; !rv:38.0) Gecko/20100101 Firefox/38.0"

      • $exitIP1 - "GET /favicon.ico HTTP/1.1" 200 "-" "Mozilla/5.0 (Windows NT 6.1; !rv:38.0) Gecko/20100101 Firefox/38.0"

      $exitIP1 is the IP shown for the circuit in Torbutton. IP2 confirmed via Atlas as Exit. So it's not images per se, but favicons that get fetched a second time, via unrelated circuit. Privacy implications?

      Trac:
      Sponsor: N/A to N/A
      Summary: Tor-browser downloads images twice to Tor-browser downloads favicon twice
      Resolution: worksforme to N/A
      Status: closed to reopened

    • C
      cypherpunks @cypherpunks ·
      Author

      Trac:
      Severity: N/A to Major

    • Georg Koppen
      Georg Koppen @gk ·

      So, there are two things here: 1) Downloading the favicon twice. I'd guess this is an underlying Mozilla problem: https://bugzilla.mozilla.org/show_bug.cgi?id=583351. 2) Downloading the favicon over a different circuit. I can observe 1), too, on some websites but it seems all those second requests go over the same circuit. Is 2) reproducible for you? If so, do you have an example site allowing us to debug the Tor Browser behavior?

      Trac:
      Status: reopened to needs_information

    • Georg Koppen
      Georg Koppen @gk ·

      #17998 (moved) is a duplicate.

      Trac:
      Cc: N/A to fxs, isis
      Keywords: N/A deleted, tbb-linkability added
      Summary: Tor-browser downloads favicon twice to Tor-browser downloads favicon twice (and over different circuits)

    • C
      cypherpunks @cypherpunks ·
      Author

      Replying to gk:

      So, there are two things here: 1) Downloading the favicon twice. I'd guess this is an underlying Mozilla problem: https://bugzilla.mozilla.org/show_bug.cgi?id=583351. 2) Downloading the favicon over a different circuit. I can observe 1), too, on some websites but it seems all those second requests go over the same circuit. Is 2) reproducible for you? If so, do you have an example site allowing us to debug the Tor Browser behavior?

      Sorry for the late reply. I doubt 1) is the cause here, ticket:17998#comment:2 would be my guess, too.

      1. It is reproducible, but: It happens only on the first request to the site, I could not trigger it a second time in the same Tor Browser session. Reloading, getting a new circuit in torbutton, closing/reopening tabs... nada. Requests to the favicon don't show up in any FF DevTool.

      Considering I don't reference the favicon in my HTML, Mozilla is doing some magic here. A quick search turned up complaints about it on Bugzilla reaching back to FF 0.10, it looks like preffing off browser.chrome.favicons disables this behavior and leaves correctly referenced favicons intact. So this might be a cheap and easy fix at the cost of loosing favicons on sites which simply dump it in their web-root directory and expect it to work (besides me and mozilla.org, nobody really seems to be doing this).

      I couldn't get my TB to log to a file as per your instruction in the other ticket, do you still want a testcase with all this info?

      Btw: opening 'Page Info' triggers resource fetches via unrelated circuits, too.

    • T
      teor @teor ·

      Replying to cypherpunks:

      Replying to gk:

      So, there are two things here: 1) Downloading the favicon twice. I'd guess this is an underlying Mozilla problem: https://bugzilla.mozilla.org/show_bug.cgi?id=583351. 2) Downloading the favicon over a different circuit. I can observe 1), too, on some websites but it seems all those second requests go over the same circuit. Is 2) reproducible for you? If so, do you have an example site allowing us to debug the Tor Browser behavior?

      Sorry for the late reply. I doubt 1) is the cause here, ticket:17998#comment:2 would be my guess, too.

      They could well be the same issue.

      1. It is reproducible, but: It happens only on the first request to the site, I could not trigger it a second time in the same Tor Browser session. Reloading, getting a new circuit in torbutton, closing/reopening tabs... nada. Requests to the favicon don't show up in any FF DevTool.

      Considering I don't reference the favicon in my HTML, Mozilla is doing some magic here. A quick search turned up complaints about it on Bugzilla reaching back to FF 0.10, it looks like preffing off browser.chrome.favicons disables this behavior and leaves correctly referenced favicons intact. So this might be a cheap and easy fix at the cost of loosing favicons on sites which simply dump it in their web-root directory and expect it to work (besides me and mozilla.org, nobody really seems to be doing this).

      See https://en.wikipedia.org/wiki/Favicon#How_to_use for a list of how browsers look for favicons.

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to cypherpunks:

      Replying to gk:

      So, there are two things here: 1) Downloading the favicon twice. I'd guess this is an underlying Mozilla problem: https://bugzilla.mozilla.org/show_bug.cgi?id=583351. 2) Downloading the favicon over a different circuit. I can observe 1), too, on some websites but it seems all those second requests go over the same circuit. Is 2) reproducible for you? If so, do you have an example site allowing us to debug the Tor Browser behavior?

      Sorry for the late reply. I doubt 1) is the cause here, ticket:17998#comment:2 would be my guess, too.

      1. It is reproducible, but: It happens only on the first request to the site, I could not trigger it a second time in the same Tor Browser session. Reloading, getting a new circuit in torbutton, closing/reopening tabs... nada. Requests to the favicon don't show up in any FF DevTool.

      Interesting. FWIW: I see favicon requests in the browser console. Still, looking at the log output visiting mozilla.org shows everything goes over the same circuit. What OS are you on?

      Considering I don't reference the favicon in my HTML, Mozilla is doing some magic here. A quick search turned up complaints about it on Bugzilla reaching back to FF 0.10, it looks like preffing off browser.chrome.favicons disables this behavior and leaves correctly referenced favicons intact. So this might be a cheap and easy fix at the cost of loosing favicons on sites which simply dump it in their web-root directory and expect it to work (besides me and mozilla.org, nobody really seems to be doing this).

      I couldn't get my TB to log to a file as per your instruction in the other ticket, do you still want a testcase with all this info?

      Yes, please. I assumed you were using Linux. If you extract the Tor Browser and change into the tor-browser_LOCALE directory, starting Tor Browser with ./start-tor-browser.desktop --log should give you a tor-browser.log file in the same directory. If you set the Torbutton logging to level 3 as described you should see the circuit isolation at work.

      Btw: opening 'Page Info' triggers resource fetches via unrelated circuits, too.

      Yeah, that's annoying and #15555 (moved) assuming you meant the view-source feature.

    • C
      cypherpunks @cypherpunks ·
      Author

      Replying to gk:

      Interesting. FWIW: I see favicon requests in the browser console. Still, looking at the log output visiting mozilla.org shows everything goes over the same circuit. What OS are you on?

      I'm on Win10 x64 and you can scratch my previous observations, I was testing a bunch of sites after flipping the aforementioned pref, obviously the requests on my site went away but mozilla.org didn't break because they don't reference a favicon, but because the secondary circuit must have timed out.

      Yes, please. I assumed you were using Linux. If you extract the Tor Browser and change into the tor-browser_LOCALE directory, starting Tor Browser with ./start-tor-browser.desktop --log should give you a tor-browser.log file in the same directory. If you set the Torbutton logging to level 3 as described you should see the circuit isolation at work.

      Can't get this to work on Windows.

      Btw: opening 'Page Info' triggers resource fetches via unrelated circuits, too. Yeah, that's annoying and #15555 (moved) assuming you meant the view-source feature.

      No, I'm talking about Tools >> Page Info, or right-clicking in a page >> View Page Info, clicking the lock or globe in the URL-bar >> more information is another way to open this, don't even need to select the media tab there.

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to cypherpunks:

      Replying to gk:

      Yes, please. I assumed you were using Linux. If you extract the Tor Browser and change into the tor-browser_LOCALE directory, starting Tor Browser with ./start-tor-browser.desktop --log should give you a tor-browser.log file in the same directory. If you set the Torbutton logging to level 3 as described you should see the circuit isolation at work.

      Can't get this to work on Windows.

      Ah, okay. After setting the log level to 3 you should be able to see the log in the browser console as well. If you need to increase the log lines available devtools.hud.loglimit.console is your friend.

      Btw: opening 'Page Info' triggers resource fetches via unrelated circuits, too. Yeah, that's annoying and #15555 (moved) assuming you meant the view-source feature.

      No, I'm talking about Tools >> Page Info, or right-clicking in a page >> View Page Info, clicking the lock or globe in the URL-bar >> more information is another way to open this, don't even need to select the media tab there.

      Thanks, that is #18030 (moved).

    • C
      cypherpunks @cypherpunks ·
      Author

      Replying to gk:

      Ah, okay. After setting the log level to 3 you should be able to see the log in the browser console as well. If you need to increase the log lines available devtools.hud.loglimit.console is your friend.

      Great, I was looking at the Web Console and Network Tools, which show nothing.

      Here's my log for the first request of the session to check.torproject.org, tor-on.png is used as favicon, not sure if anything but the stuff around the two GETs near the end is relevant:

      [01-13 14:32:02] Torbutton INFO: tor SOCKS: https://check.torproject.org/?lang=en_US via torproject.org:0
GET 
https://check.torproject.org/ [HTTP/1.1 200 OK 9469ms]
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[01-13 14:32:02] Torbutton INFO: controlPort >> 650 STREAM 25 NEW 0 check.torproject.org:443 SOURCE_ADDR=127.0.0.1:49929 PURPOSE=USER
[01-13 14:32:02] Torbutton INFO: controlPort >> 650 STREAM 25 SENTCONNECT 9 check.torproject.org:443
[01-13 14:32:02] Torbutton INFO: streamEvent.CircuitID: 9
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo circuit-status



[01-13 14:32:02] Torbutton INFO: controlPort >> 250+circuit-status=

8 BUILT $18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E~cocoadrome,$F530691F6850CAFFFCCF247B579FA214CA815105~ThemWaffles,$B486925DC901969CCE2B371E93740CF98C30539D~AS250 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2016-01-13T14:24:01.742280

2 BUILT $18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E~cocoadrome BUILD_FLAGS=ONEHOP_TUNNEL,IS_INTERNAL,NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2016-01-13T14:23:01.756129

7 BUILT $18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E~cocoadrome,$DB19E709C9EDB903F75F2E6CA95C84D637B62A02~wikimediaeqiad1,$278E2E0EE678D3DC807612503CA9FCA78F40B06C~aTomicExitDE2a BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2016-01-13T14:23:04.365583 SOCKS_USERNAME="--unknown--" SOCKS_PASSWORD="0"

6 BUILT $18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E~cocoadrome,$951BDBA042A69FE8577129EA301B027A879B985B~SGGSUK7,$231C2B9C8C31C295C472D031E06964834B745996~torpidsDEdomainf BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2016-01-13T14:23:03.740564

5 BUILT $18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E~cocoadrome,$28DD2A2049E0AE7AB53D6FA38FDB9EAD35BE1FE7~unixio,$E0EB93F8F73F9B3794CCAE08DB1DCFD283F00277~nullstreet BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2016-01-13T14:23:02.740534

9 BUILT $18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E~cocoadrome,$0744F2AE098BAD9F1A0FEF109C01E621FB6A4600~xkeyscore,$0111BA9B604669E636FFD5B503F382A4B7AD6E80~DigiGesTor1e1 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2016-01-13T14:32:02.303309 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="0"

.

250 OK
[01-13 14:32:02] Torbutton INFO: controlPort << getconf bridge



[01-13 14:32:02] Torbutton INFO: controlPort >> 250 Bridge
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo ns/id/18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E



[01-13 14:32:02] Torbutton INFO: controlPort >> 250+ns/id/18CD08992B2E3EF52C0968E91AA7BDF9D7F9B91E=

r cocoadrome GM0ImSsuPvUsCWjpGqe9+df5uR4 bfj6NsawDrOJOEGTpOq+OXdV3jw 2016-01-13 01:45:06 46.101.241.28 9001 9030

s Fast Guard HSDir Running Stable V2Dir Valid

w Bandwidth=26100

.

250 OK
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo ip-to-country/46.101.241.28



[01-13 14:32:02] Torbutton INFO: controlPort >> 250-ip-to-country/46.101.241.28=de

250 OK
[01-13 14:32:02] Torbutton INFO: controlPort << getconf bridge



[01-13 14:32:02] Torbutton INFO: controlPort >> 250 Bridge
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo ns/id/0744F2AE098BAD9F1A0FEF109C01E621FB6A4600



[01-13 14:32:02] Torbutton INFO: controlPort >> 250+ns/id/0744F2AE098BAD9F1A0FEF109C01E621FB6A4600=

r xkeyscore B0TyrgmLrZ8aD+8QnAHmIftqRgA f2lFigU6nLfEFZs8jnAIiyylgYw 2016-01-13 12:45:51 195.154.110.121 443 0

s Fast Running Stable Valid

w Bandwidth=4320

.

250 OK
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo ip-to-country/195.154.110.121



[01-13 14:32:02] Torbutton INFO: controlPort >> 250-ip-to-country/195.154.110.121=fr

250 OK
[01-13 14:32:02] Torbutton INFO: controlPort << getconf bridge



[01-13 14:32:02] Torbutton INFO: controlPort >> 250 Bridge
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo ns/id/0111BA9B604669E636FFD5B503F382A4B7AD6E80



[01-13 14:32:02] Torbutton INFO: controlPort >> 250+ns/id/0111BA9B604669E636FFD5B503F382A4B7AD6E80=

r DigiGesTor1e1 ARG6m2BGaeY2/9W1A/OCpLetboA Ia8AF21GtWWADpmb9sVNMa6cD9g 2016-01-13 07:44:52 176.10.104.240 443 80

s Exit Fast Guard HSDir Running Stable V2Dir Valid

w Bandwidth=35900

.

250 OK
[01-13 14:32:02] Torbutton INFO: controlPort << getinfo ip-to-country/176.10.104.240



[01-13 14:32:02] Torbutton INFO: controlPort >> 250-ip-to-country/176.10.104.240=ch

250 OK
[01-13 14:32:10] Torbutton INFO: controlPort >> 650 STREAM 25 REMAP 9 38.229.72.22:443 SOURCE=EXIT
[01-13 14:32:10] Torbutton INFO: controlPort >> 650 STREAM 25 SUCCEEDED 9 38.229.72.22:443
[01-13 14:32:10] Torbutton INFO: tor SOCKS: http://ocsp.digicert.com/ via torproject.org:0
POST 
http://ocsp.digicert.com/ [HTTP/1.1 200 OK 359ms]
[01-13 14:32:10] Torbutton INFO: controlPort >> 650 STREAM 26 NEW 0 ocsp.digicert.com:80 SOURCE_ADDR=127.0.0.1:49930 PURPOSE=USER
[01-13 14:32:10] Torbutton INFO: controlPort >> 650 STREAM 26 SENTCONNECT 9 ocsp.digicert.com:80
[01-13 14:32:11] Torbutton INFO: controlPort >> 650 STREAM 26 REMAP 9 72.21.91.29:80 SOURCE=EXIT
[01-13 14:32:11] Torbutton INFO: controlPort >> 650 STREAM 26 SUCCEEDED 9 72.21.91.29:80
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[01-13 14:32:11] Torbutton INFO: tor SOCKS: https://check.torproject.org/torcheck/img/tor-on.png via torproject.org:0
GET 
https://check.torproject.org/torcheck/img/tor-on.png [HTTP/1.1 200 OK 266ms]
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
getFirstPartyURI failed for https://check.torproject.org/torcheck/img/tor-on.png: 0x80070057
[01-13 14:32:11] Torbutton INFO: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [mozIThirdPartyUtil.getFirstPartyURIFromChannel]
[01-13 14:32:11] Torbutton INFO: tor SOCKS isolation catchall: https://check.torproject.org/torcheck/img/tor-on.png via --unknown--:0
getFirstPartyURI failed for https://check.torproject.org/torcheck/img/tor-on.png: 0x80070057
GET 
https://check.torproject.org/torcheck/img/tor-on.png [HTTP/1.1 200 OK 1858ms]
[01-13 14:32:11] Torbutton INFO: tor SOCKS: https://check.torproject.org/torcheck/img/tor-on.png via torproject.org:0
[01-13 14:32:11] Torbutton INFO: controlPort >> 650 STREAM 27 NEW 0 check.torproject.org:443 SOURCE_ADDR=127.0.0.1:49931 PURPOSE=USER
[01-13 14:32:11] Torbutton INFO: controlPort >> 650 STREAM 27 SENTCONNECT 7 check.torproject.org:443
getFirstPartyURI failed for chrome://browser/content/browser.xul: 0x80070057
[01-13 14:32:11] Torbutton INFO: controlPort >> 650 STREAM 27 REMAP 7 38.229.72.22:443 SOURCE=EXIT
[01-13 14:32:11] Torbutton INFO: controlPort >> 650 STREAM 27 SUCCEEDED 7 38.229.72.22:443
    • Georg Koppen
      Georg Koppen @gk ·

      Okay, this seems to be a Windows-only issue. Fun. I can see the same behavior on a Windows 8 box but neither on OS X nor Linux. At least we can debug and fix it now, thanks cypherpunk. Oh, and FWIW you might want to consider to change your guard node (e.g. by using a fresh Tor Browser and re-customizing that one, or getting rid of your state file) as you exposed it in your log in comment:13 in case you did not do that already.

      Trac:
      Keywords: N/A deleted, TorBrowserTeam201601 added
      Status: needs_information to assigned
      Cc: fxs, isis to fxs, isis, arthuredelstein

    • Georg Koppen
      Georg Koppen @gk ·

      Putting stuff on the radar for February.

      Trac:
      Keywords: TorBrowserTeam201601 deleted, TorBrowserTeam201602 added

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Keywords: TorBrowserTeam201602 deleted, TorBrowserTeam201603 added

    • B
      bugzilla @bugzilla ·

      Issue wasn't found on Win XP.

      Trac:
      Reviewer: N/A to N/A

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Summary: Tor-browser downloads favicon twice (and over different circuits) to Tor-browser downloads favicon twice (and over different circuits) on Windows

    • B
      bugzilla @bugzilla ·

      As #17761 (moved) was closed, moving to this ticket:

      browser.chrome.site_icons set to false until fixed. (and, please, make it default for TBB until these vulnerabilities are fixed.) And why have you left this bug in TorBrowserTeam201603?

      UPD: this seems to be an underlying base for Options / General / Show tab previews in the Windows taskbar.

    • B
      bugzilla @bugzilla ·

      Why can't you temporarily apply the fix (as you did in #16998 (moved)) in comment:19? Crash, #18513 (moved), this ticket, what else is acceptable in stable?

      Trac:
      Keywords: TorBrowserTeam201603 deleted, TorBrowserTeam201606 added

    • Georg Koppen
      Georg Koppen @gk ·

      See: comment:13:ticket:17761 for why. I only tested it back then in the crash context, though. And, again, please don't mess with the keywords. Especially not those that are responsible for tracking our monthly workload. Thanks.

      Trac:
      Keywords: TorBrowserTeam201606 deleted, N/A added

    • B
      bugzilla @bugzilla ·

      Do you think it wasn't seen? How did you test it? That pref completely disables favicons, they even don't load from websites. Or is there a hole that Mozilla doesn't know? Keyword was replaced to return this ticket to your radar in order to raise your attention. But if it's only a mess for you, then sorry. It seems we have different points of view about security.

    • Georg Koppen
      Georg Koppen @gk ·

      I flipped the preference and Tor Browser was still crashing. Apart from that, instead of messing with our keywords providing a workaround patch (be sure that you disable favicons only for Windows), setting the ticket to needs_review and linking, ideally, to test builds would be a much better approach. Above all it would show that you are really caring about this topic.

    • Georg Koppen
      Georg Koppen @gk ·

      I bet this is happening in WindowsPreviewPerTab.jsm. If so, this is probably the windows per-tab taskbar preview ("Aero Peek") functionality which is turned off but still doing network requests. Mozilla hit this while trying to fix the issues mentioned in #18513 (moved).

    • Georg Koppen
      Georg Koppen @gk ·

      Fixed with the switch to 45.3.0esr.

      Trac:
      Keywords: N/A deleted, ff45-esr-will-have added
      Status: assigned to closed
      Resolution: N/A to fixed

    • B
      bugzilla @bugzilla ·

      Replying to gk:

      I bet this is happening in WindowsPreviewPerTab.jsm. It was mentioned in comment:19 If so, this is probably the windows per-tab taskbar preview ("Aero Peek") functionality which is turned off No, it's not turned off, just hidden. but still doing network requests. No, it's not doing that, but that bug does Mozilla hit this while trying to fix the issues mentioned in #18513 (moved).

    • Trac closed

      closed

    • bugzilla mentioned in issue #17761 (moved)

      mentioned in issue #17761 (moved)

    • Georg Koppen mentioned in issue #17998 (moved)

      mentioned in issue #17998 (moved)

    • Trac moved to tpo/applications/tor-browser#16747 (closed)

      moved to tpo/applications/tor-browser#16747 (closed)

    Please register or sign in to reply