All tabs often crash when closing one tab

Since Tor 7 the thing described in the summary happens very often. About one in five to ten of the times that I close a tab, all the tabs crash and need to be reloaded. I tried version 7 stable and unstable. Clean install, removed the old dir. No addons added.

This didn't happen with version 6. Is v6 still available from official sources?

Trac:
Username: SaturnusDJ

added GeorgKoppen201709 TorBrowserTeam201709R component::applications/tor browser owner::tbb-team priority::medium reporter::SaturnusDJ resolution::fixed severity::normal status::closed tbb-crash tbb-e10s type::defect labels

Do you have any way to reproduce this? If not what do you get when using the browser console Ctrl+Shift+J when this crash happens?

Trac:
Owner: N/A to tbb-team
Status: new to needs_information
Component: - Select a component to Applications/Tor Browser

Probably similar to https://trac.torproject.org/projects/tor/ticket/23050. The workaround given there seems to work.

Trac:
Username: SaturnusDJ

Replying to cypherpunks:

Do you have any way to reproduce this? If not what do you get when using the browser console Ctrl+Shift+J when this crash happens? I can't find a way to make the crash happen on command. It seems random. The way of closing the tab doesn't seem to have a huge impact. Clicking the X to close or using ctrl + w, same result.

I will try console soon.

Trac:
Username: SaturnusDJ

Replying to SaturnusDJ:

Probably similar to https://trac.torproject.org/projects/tor/ticket/23050. The workaround given there seems to work.

The workaround consists of disabling e10s.

Trac:
Keywords: N/A deleted, tbb-e10s added

Console:

TelemetryStopwatch: key "FX_PAGE_LOAD_MS" was already initialized TelemetryStopwatch.jsm:282
	this.TelemetryStopwatchImpl.start re[/gre/modules/TelemetryStopwatch.jsm:282:7](/gre/modules/TelemetryStopwatch.jsm:282:7)
	this.TelemetryStopwatch.start re[/gre/modules/TelemetryStopwatch.jsm:136:12](/gre/modules/TelemetryStopwatch.jsm:136:12)
	TabsProgressListener.onStateChange chrome://browser/content/browser.js:4852:11
	callListeners chrome://browser/content/tabbrowser.xml:506:24
	_callProgressListeners chrome://browser/content/tabbrowser.xml:527:13
	mTabProgressListener/<._callProgressListeners chrome://browser/content/tabbrowser.xml:577:22
	mTabProgressListener/<.onStateChange chrome://browser/content/tabbrowser.xml:762:15
	_loadURIWithFlags chrome://browser/content/browser.js:852:7
	loadURIWithFlags chrome://browser/content/tabbrowser.xml:7381:13
	loadURI/< chrome://global/content/bindings/browser.xml:120:15
	_wrapURIChangeCall chrome://global/content/bindings/browser.xml:49:17
	loadURI chrome://global/content/bindings/browser.xml:119:13
	reviveCrashedTab re[//modules/sessionstore/SessionStore.jsm:2635:5](//modules/sessionstore/SessionStore.jsm:2635:5)
	reviveCrashedTab re[//modules/sessionstore/SessionStore.jsm:339:12](//modules/sessionstore/SessionStore.jsm:339:12)
	onxbloop-browser-crashed chrome://browser/content/tabbrowser.xml:5113:13

TelemetryStopwatch: requesting elapsed time for nonexisting stopwatch. Histogram: "FX_PAGE_LOAD_MS", key: "null" TelemetryStopwatch.jsm:297
	this.TelemetryStopwatchImpl.timeElapsed re[/gre/modules/TelemetryStopwatch.jsm:297:7](/gre/modules/TelemetryStopwatch.jsm:297:7)
	this.TelemetryStopwatchImpl.finish re[/gre/modules/TelemetryStopwatch.jsm:315:17](/gre/modules/TelemetryStopwatch.jsm:315:17)
	this.TelemetryStopwatch.finish re[/gre/modules/TelemetryStopwatch.jsm:192:12](/gre/modules/TelemetryStopwatch.jsm:192:12)
	TabsProgressListener.onStateChange chrome://browser/content/browser.js:4857:11
	callListeners chrome://browser/content/tabbrowser.xml:506:24
	_callProgressListeners chrome://browser/content/tabbrowser.xml:527:13
	mTabProgressListener/<._callProgressListeners chrome://browser/content/tabbrowser.xml:577:22
	mTabProgressListener/<.onStateChange chrome://browser/content/tabbrowser.xml:762:15
	restoreHistory re[//modules/sessionstore/ContentRestore.jsm:122:5](//modules/sessionstore/ContentRestore.jsm:122:5)
	bound restoreHistory self-hosted:919:17
	restoreHistory chrome://browser/content/content-sessionStore.js:158:5
	MessageListener.receiveMessage chrome://browser/content/content-sessionStore.js:140:9

Trac:
Username: SaturnusDJ

Interesting. I assume this is happening on a Windows OS (which version?)? And do you use Tor Browser as we ship it or do you make any modifications? Like enabling disk storage or something else? If you do these modifications do the crashes occur as well if you use just the bundle as we ship it?

Trac:
Keywords: N/A deleted, tbb-crash added

Win 10. No mods.

Trac:
Username: SaturnusDJ

Thanks. I'd really appreciate it if you could help us tracking down that bug as we don't have machines where we can reproduce it.

So, could you test whether this problem is visible as well if you test on your machine with a normal Firefox ESR 52? You can find bundles on: https://www.mozilla.org/en-US/firefox/organizations/all/ (not choosing one of the Windows 64-bit binaries as Tor Browser as we ship it is still a 32-bit application).

I think I've found a way to reproduce this or at least a pretty similar issue.

Trac:
Status: needs_information to assigned
Keywords: N/A deleted, TorBrowserTeam201709, GeorgKoppen201709 added

This doesn't seem to be Windows specific as it happened for me on a Linux box. Difficult to reproduce tho...

Got it for the first time. Last words were:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.host]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: re[/gre/modules/WebRequest.jsm](/gre/modules/WebRequest.jsm) :: runChannelListener :: line 727"  data: no] (unknown)
	runChannelListener re[/gre/modules/WebRequest.jsm:727:22](/gre/modules/WebRequest.jsm:727:22)
	observe re[/gre/modules/WebRequest.jsm:504:9](/gre/modules/WebRequest.jsm:504:9)
[NoScript HTTPS] AUTOMATIC SECURE on https://pad.riseup.net: io=pN9LxxveKzEnJEhsAVGw; domain=pad.riseup.net; path=/; HttpOnly; Secure
NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStreamListener.onStartRequest]  WebRequest.jsm:342
[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStreamListener.onStopRequest]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: re[/gre/modules/WebRequest.jsm](/gre/modules/WebRequest.jsm) :: onStopRequest :: line 347"  data: no]  (unknown)
	onStopRequest re[/gre/modules/WebRequest.jsm:347:7](/gre/modules/WebRequest.jsm:347:7)

comment:5 is what you get after reloading the page from about:tabcrashed.

I am not sure if there is just one underlying cause for this bug, but here is a fix for one scenario: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug23393-01

The steps to reproduce are:

1. Open https://www.google.com/ in a tab.
2. Open https://developer.mozilla.org/samples/video/chroma-key/index.xhtml in a second tab.
3. Click to play the video.
4. After the canvas prompt is showing and while the video is still playing, close the tab.

The developer.mozilla.org page tries repeatedly to extract canvas data, which means the canvas prompt codepath is being exercised over and over again, even while the tab is closing. This leads to an error in the main/parent process, after which it kills the content (child) process. I don't think this is exploitable from a security perspective, but it is disruptive if you have a few tabs open.

Trac:
Cc: N/A to brade, mcs
Status: assigned to needs_review
Keywords: TorBrowserTeam201709 deleted, TorBrowserTeam201709R added

https://bugzilla.mozilla.org/show_bug.cgi?id=967895 comment 75 has a different idea on how to solve this issue.

Replying to gk:

https://bugzilla.mozilla.org/show_bug.cgi?id=967895 comment 75 has a different idea on how to solve this issue.

Kathy and I are not so sure about that proposed fix... I made a comment in the Bugzilla bug.

Replying to mcs:

I am not sure if there is just one underlying cause for this bug, but here is a fix for one scenario: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug23393-01

The steps to reproduce are:

1. Open https://www.google.com/ in a tab.
2. Open https://developer.mozilla.org/samples/video/chroma-key/index.xhtml in a second tab.
3. Click to play the video.
4. After the canvas prompt is showing and while the video is still playing, close the tab.

The developer.mozilla.org page tries repeatedly to extract canvas data, which means the canvas prompt codepath is being exercised over and over again, even while the tab is closing. This leads to an error in the main/parent process, after which it kills the content (child) process. I don't think this is exploitable from a security perspective, but it is disruptive if you have a few tabs open.

Looks good to me. I was wondering whether we should squash that commit with the main canvas related one. Or do you think this issue merits its own commit? I am inclined to say, let's squash them. If you agree could you revise your commit?

Trac:
Status: needs_review to needs_information

Looks good to me too. I wonder if there's an advantage in keeping this commit separate, because the main canvas patch is in the process of getting uplifted and we don't want to lose track of this extra fix. Though I'm not sure if this fix is relevant to the Mozilla version.

Replying to arthuredelstein:

Looks good to me too. I wonder if there's an advantage in keeping this commit separate, because the main canvas patch is in the process of getting uplifted and we don't want to lose track of this extra fix. Though I'm not sure if this fix is relevant to the Mozilla version.

I brought this issue up on the Mozilla ticket and they plan to include that fix (the issue is visible there as well).