When I have a hidden blank tab (in another group for example) and call ss.setTabState(blankTab) I expect it not to be restored but be ready for restoration when the corresponding group gets shown again. That's because of setTabState() calls: > this.restoreHistoryPrecursor(window, [aTab], [tabState], 0, 0, 0); And restoreHistoryPrecursor contains these lines: > let unhiddenTabs = aTabData.filter(function (aData) !aData.hidden).length; > > // if all tabs to be restored are hidden, make the first one visible > if (unhiddenTabs == 0) { > aTabData[0].hidden = false; > } else if (aTabs.length > 1) { > ... > } This results in very strange results (especially in combination with Panorama) as the tab gets shown, loads and is hidden again.

This patch moves the code that unhides the first tab (to have at least one shown tab) to restoreWindow().

Comment on attachment 573511 [details] [diff] [review] patch v1 Review of attachment 573511 [details] [diff] [review]: ----------------------------------------------------------------- Seems fine by me, just add a test before landing. Thanks Tim!

Added a sessionstore test. Alas, there are intermittent try failures which need to be investigated: browser_tabview_bug627288.js times out because the tab passed to ss.restoreTab() seems to be removed from its window. I think there's some issue with setTimeout() and the tab being removed in the meantime...

I know you're a busy man Tim, but any update on those oranges?

It's been in my todo list for weeks and I've always wanted to look at this again. Hope I can find the time soon. Don't hesitate to steal this in the meantime if anyone feels like it :)

Comment on attachment 580303 [details] [diff] [review] patch v2 (with test) So I pushed it to try again and had one strange intermittent error that didn't seem to recur: https://tbpl.mozilla.org/?tree=Try&rev=ad05cc963b54 A second try push with some debug output didn't show it, too: https://tbpl.mozilla.org/?tree=Try&rev=8ebc88495609