Bug 1389784: Recover gracefully when we fail to create a tab browser. r=mystor

There are some cases where we fail to create a tab's browser due to the sanity
checks in _createBrowser(). While in theory those should never fail, in
practice they seem to. And when they do, they leave the browser in an
inconsistent state.

This change should both prevent the worst effects of these failures, and also
give use better error reporting so that we can properly debug them.

MozReview-Commit-ID: EZjKN9URw5X

--HG--
extra : rebase_source : 100b36b89b1c09087230f5e5cb4d6822e18e6daf
extra : amend_source : d054df358bf346ec0a340c4e7d6b0a99f3ceb646
This commit is contained in:
Kris Maglione 2017-10-03 12:56:24 -07:00
Родитель e147b24667
Коммит 4f1cf2c5d1
1 изменённых файлов: 90 добавлений и 77 удалений

Просмотреть файл

@ -2697,6 +2697,10 @@
this.tabContainer.appendChild(t);
let usingPreloadedContent = false;
let b;
try {
// If this new tab is owned by another, assert that relationship
if (aOwner)
t.owner = aOwner;
@ -2727,9 +2731,6 @@
: E10SUtils.getRemoteTypeForURI(aURI, gMultiProcessBrowser,
aPreferredRemoteType);
let b;
let usingPreloadedContent = false;
// If we open a new tab with the newtab URL in the default
// userContext, check if there is a preloaded browser ready.
// Private windows are not included because both the label and the
@ -2780,6 +2781,18 @@
} else {
this._insertBrowser(t, true);
}
} catch (e) {
Cu.reportError("Failed to create tab");
Cu.reportError(e);
t.remove();
if (t.linkedBrowser) {
this._tabFilters.delete(t);
this._tabListeners.delete(t);
let notificationbox = this.getNotificationBox(t.linkedBrowser);
notificationbox.remove();
}
throw e;
}
// Dispatch a new tab notification. We do this once we're
// entirely done, so that things are in a consistent state