Extension should try to unsuspend all tabs before it is uninstalled

[dandv]

Just channeling a Feb 2013 complaint from the user reviews. Not sure if this has been fixed in the meantime.

removed [the extension] from Chrome. Surprise: IT CLOSES ALL THE TABS YOU HAD SUSPENDED, with NO chance of restoring them (unless you go back in your history - which is useless if you, like me open dozens of tabs every day, and want to reopen a tab you had open some weeks ago).

[deanoemcke]

I agree this is a very unfortunate behaviour of the extension. However, due to the way that the tabs are suspended there is nothing I can do about it. The pages are unloaded by redirecting to a locally hosted webpage that is part of the extension. When the extension is uninstalled, the webpage that it refers to no longer exists, and so chrome removes that tab from the window.

The workaround is to 'unsuspend all tabs' before uninstalling. However, I appreciate not everyone will know to do this in advance.

[deanoemcke]

To investigate:

@ronin13 suggests that the chrome.runtime.onSuspend listener never gets called due to the extension using a persistent background page: #418

This is because the extension is not using event pages.

Hence,

//wishful thinking here that a synchronus iteration through tab views will enable them
//to unsuspend before the application closes
chrome.runtime.onSuspend.addListener(function () {
    chrome.extension.getViews({type: 'tab'}).forEach(function (view) {
        view.location.reload();
    });
});

in background.js never gets triggered.

It needs the background pages to be converted into event pages as described here: https://developer.chrome.com/extensions/event_pages

[deanoemcke]

This issue is blocked as there is currently no way for me to perform any asynchronous cleanup job after the user chooses to uninstall (or disable) the extension.

Here is a chromium bug report requesting this be implemented:

• https://bugs.chromium.org/p/chromium/issues/detail?id=19383

One possible (very inadequate) fallback is to redirect the user to a url after uninstallation. This will not prevent users from losing their lost tabs, but it could at least take them to a page which could offer advice on how to recover the lost tabs.

[meden]

Hello!

This issue is blocked as there is currently no way for me to perform any asynchronous cleanup job after the user chooses to uninstall (or disable) the extension.

Here are some chromium bug reports requesting this be implemented

The issue you're referring has been marked as fixed on Jul 15 2015...

Thanks for your work!

[fwextensions]

Here's a thoroughly kludgy idea: on suspended.html, inject a hidden iframe pointing at a page on greatsuspender.github.io, which the extension has access to. Then inject a content script on that page with a dump of the currently suspended page data, which the script then writes to the local storage of the greatsuspender.github.io page.

When the extension is uninstalled, redirect to that page. It can then read its data from local storage and offer to reopen all the suspended, and now closed, pages. I'm betting Chrome would prevent a webpage from opening dozens of new tabs, so the user might have to manually click each one to reopen it. But better than losing it altogether.

This SO page suggests it might be possible: https://stackoverflow.com/questions/15288648/chrome-extension-write-to-local-storage-of-a-different-domain

But I go back to my suggestion in #688 of redirecting suspended pages to a web-served page instead of a local one, so that it's not closed on uninstall. Obviously doesn't help with the next update, but would with all future ones. May well be some impediment I haven't thought of, though.

[deanoemcke]

@meden i don't think it was marked as fixed? there was a resolution in the form of being able to specify an uninstall url which the user would get redirected to after uninstallation. however, this does not block the uninstallation process. it merely opens the requested url maybe before / maybe after the uninstall has taken place.

[deanoemcke]

@fwextensions thanks for the idea.
it may well work. i will do some investigation at some point. not for this upcoming release though :(

[meden]

@deanoemcke yes, you're right, the issue has been merged with a related, but different, one. Comment 12, though, mentions an event callback (although I imagine you already looked into it...)