#23393 closed defect (fixed)

All tabs often crash when closing one tab

Reported by: SaturnusDJ Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-e10s, tbb-crash, TorBrowserTeam201709R, GeorgKoppen201709
Cc: brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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?

Child Tickets

Change History (21)

comment:1 Changed 17 months ago by cypherpunks

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team
Status: newneeds_information

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?

comment:2 Changed 17 months ago by SaturnusDJ

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

comment:3 in reply to:  1 Changed 17 months ago by 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.

comment:4 in reply to:  2 Changed 17 months ago by cypherpunks

Keywords: tbb-e10s added

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.

comment:5 Changed 17 months ago by SaturnusDJ

Console:

TelemetryStopwatch: key "FX_PAGE_LOAD_MS" was already initialized TelemetryStopwatch.jsm:282
	this.TelemetryStopwatchImpl.start resource://gre/modules/TelemetryStopwatch.jsm:282:7
	this.TelemetryStopwatch.start resource://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 resource:///modules/sessionstore/SessionStore.jsm:2635:5
	reviveCrashedTab resource:///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 resource://gre/modules/TelemetryStopwatch.jsm:297:7
	this.TelemetryStopwatchImpl.finish resource://gre/modules/TelemetryStopwatch.jsm:315:17
	this.TelemetryStopwatch.finish resource://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 resource:///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

comment:6 Changed 17 months ago by gk

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?

comment:7 Changed 17 months ago by gk

Keywords: tbb-crash added

comment:8 Changed 17 months ago by SaturnusDJ

Win 10. No mods.

comment:9 Changed 17 months ago by gk

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).

Last edited 17 months ago by gk (previous) (diff)

comment:10 Changed 17 months ago by gk

Keywords: TorBrowserTeam201709 GeorgKoppen201709 added
Status: needs_informationassigned

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

comment:11 Changed 17 months ago by cypherpunks

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

Last edited 17 months ago by cypherpunks (previous) (diff)

comment:12 Changed 16 months ago by cypherpunks

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 :: resource://gre/modules/WebRequest.jsm :: runChannelListener :: line 727"  data: no] (unknown)
	runChannelListener resource://gre/modules/WebRequest.jsm:727:22
	observe resource://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 :: resource://gre/modules/WebRequest.jsm :: onStopRequest :: line 347"  data: no]  (unknown)
	onStopRequest resource://gre/modules/WebRequest.jsm:347:7

comment:13 Changed 16 months ago by cypherpunks

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

comment:14 Changed 16 months ago by mcs

Cc: brade mcs added
Keywords: TorBrowserTeam201709R added; TorBrowserTeam201709 removed
Status: assignedneeds_review

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.

comment:15 Changed 16 months ago by gk

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

comment:16 in reply to:  15 Changed 16 months ago by mcs

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.

comment:17 in reply to:  14 Changed 16 months ago by gk

Status: needs_reviewneeds_information

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?

comment:18 Changed 16 months ago by 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.

comment:19 in reply to:  18 Changed 16 months ago by gk

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).

comment:20 Changed 16 months ago by mcs

Status: needs_informationneeds_review

comment:21 Changed 16 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Thanks. Merged to tor-browser-52.4.0esr-7.0-1 (commit 852e4a1ef17e19ea5f57072f1ea3779107e7dce2) and cherry-picked to `tor-browser-52.3.0esr-7.5-2 (commit 69666b09b12a51ce30d7b0d0e669eb773aca4e0f).

Note: See TracTickets for help on using tickets.