Since bug 664549 landed, I see this message a couple of times in a mochitest-browser-chrome log, e.g.: TEST-INFO | chrome://mochitests/content/browser/browser/base/content/test/tabview/browser_tabview_bug591706.js | Console message: TypeError: item.tab is null = {fileName: 'chrome://browser/content/tabview.js', lineNumber: 3298, } That line appears to be in GroupItem_remove: // if a blank tab is selected while restoring a tab the blank tab gets // removed. we need to keep the group alive for the restored tab. if (item.tab._tabViewTabIsRemovedAfterRestore) options.dontClose = true; Two thoughts: - Apparently GroupItem_remove is called after TabItems_unlink -- is this expected? - _tabViewTabIsRemovedAfterRestore really shouldn't be set on the tab, it should be a flag on the item.

(In reply to comment #0) > - Apparently GroupItem_remove is called after TabItems_unlink -- is this > expected? It's expected because in GroupItem.destroy() we first try to close a tab and only if that succeeded we're removing it from the group. > - _tabViewTabIsRemovedAfterRestore really shouldn't be set on the tab, it > should be a flag on the item. That is the easiest solution and what the patch does.

This is fixed by bug 663421 because the failing LOC is removed. The only place where we access tab._tabViewTabIsRemovedAfterRestore is now in onTabClose(tab) where an xulTab is passed. So I think we should not change the current behavior and let it remain a flag on the xulTab.

It doesn't belong on the tab, never did... This is all tabview code.

(In reply to comment #3) > It doesn't belong on the tab, never did... This is all tabview code. Yeah, you're right. Removed the groupitems.js changes based on bug 663421. Did you remove the bug dependencies intentionally?

Comment on attachment 540041 [details] [diff] [review] patch v2 (dependencies got cleared due to my comment colliding with your change to the bug)

Pushed: http://hg.mozilla.org/mozilla-central/rev/b3b509e9fbde