(This happens only when TabCandy was activated before) 1. Create a group with 2 tabs (one of them blank) 2. Close the non-blank tab 3. Press Shift+Ctrl+T Actual Result: TabCandy is shown because the active group was deleted in background. Expected Result: Stay in chrome window with the closed tab restored.

(In reply to comment #0) > Actual Result: > TabCandy is shown because the active group was deleted in background. At this point, if I press Ctrl+E to try to un-invoke TabCandy, it *starts* to zoom up my non-blank tab, but then fails and snaps back to the TabCandy view. The next Ctrl+E after that succeeds, though.

(In reply to comment #1) > At this point, if I press Ctrl+E to try to un-invoke TabCandy, it *starts* to > zoom up my non-blank tab, but then fails and snaps back to the TabCandy view. > The next Ctrl+E after that succeeds, though. Yeah you're right. I already fixed this issue in bug 624265 but we decided to split the patch. So there'll be patch later today.

Passed try.

Comment on attachment 502964 [details] [diff] [review] patch v1 >+ prepareUndoCloseTab: function(blankTabToRemove) { >+ if (this._window) { > this._window.UI.restoredClosedTab = true; >+ >+ if (blankTabToRemove) >+ blankTabToRemove.tabItem.isRemovedAfterRestore = true; It is possible to get into this situation with a blank pinned tab. This patch should take that into account. Perhaps instead of tacking something onto .tabItem, you should attach it directly to the xul:tab (i.e. blankTabToRemove in this case), like ._tabViewTabIsRemovedAfterRestore. Flagging Dao for feedback on this suggestion.

bugspam. Moving b10 to b11

bugspam. Removing b10

Pushed to try.

Passed try.

Comment on attachment 508069 [details] [diff] [review] patch v2 Looks good

Comment on attachment 508069 [details] [diff] [review] patch v2 This technically needs a browser peer to look at it, but I don't think the one line change actually matters enough to worry about it.

verified with nightly build of minefield.