+1
Fixed

Incognito windows leave an unremovable ghost sidebar entry upon closing the last of them

Zorael 8 years ago updated by Joel Thornton 8 years ago 0

Kubuntu linux 12.10 alpha 3, running Chromium 2.0.1229.6 (r151414). Sidewise version is up to date as of 12-08-23 and its version is listed as 2012.8.14.0.


I have set the browser to allow Sidewise in incognito mode, and as I open new windows they show up properly in the sidebar. However, upon closing the very last open incognito window, by any other way than via the sidebar context menu, that one remains there listed as 'Window (0 pages)' until browser restart or extension unload/reload.


So if I click Ctrl+Shift+N to open an incognito window, then hitting Ctrl+W to close it by closing its only tab, and repeat this ten times, then ten ghost incognito windows will clutter the sidebar. If I open ten such windows at once , on the other hand, and then close them all (as opposed to closing each before opening the next), only the last one will leave a ghost. If I remember to close that last one via the sidebar, by holding the right mouse button on it and picking 'Close window', its entry is properly removed and no ghosts remain.


If an incognito window only has one tab, hibernating it (and thus closing the window) has roughly the same effect -- except the tab will remain as well, impossible to wake but possible close via the sidebar context menu. Attempting to close the window the same way still does nothing.


As they don't really exist, tabs cannot be dropped into them. They remain even when refreshing the sidebar page (F5), but as mentioned reloading the extension or toggling allowing it in incognito mode makes it reindex tabs and return to sanity.


Normal (non-incognito) windows don't seem to exhibit this behavior, and when they on occasion do stick as ghosts with 0 pages they can always be force-closed via the context menu.


In the console with debugging enabled I see that onWindowRemoved is never executed for those ghost-leaving windows. But it does get executed for non-last incognito windows, so logically the event listener must be registering events even in incognito.



Chromium bug? If so, forcing a complete tab/window reindex might do as a workaround, perhaps when onTabRemoved isn't followed up shortly afterwards by either an onWindowRemoved or an onTabActivated.


(As a small sidenote; the ability to reindex on demand would be useful in general, such as to fix those occasionally invisible tabs, or to get tabs listed as in non-existent windows back in their place.)

Answer

Answer
Fixed

This should be pretty much fixed in the new 2012.10.18.1 release.

Sidewise now checks for and and removes zero-child window rows in cases where Chrome doesn't fire its usual onWindowRemoved event -- as is seemingly often the case with incognito windows.

Please let me know if you're still seeing this problem after updating.

Under review

This does sound like a Chromium or Linux-specific bug. On my Windows Server 2008R2 / Chrome 21.0.1180.79 m setup, I can do Ctrl+Shift+N, Ctrl+W and the incognito window entry in the tree immediately disappears as one would expect.

What about this solution?: after onTabRemoved, check if the containing window node now has zero children, and remove it if so. I *think* this would yield the correct result if onWindowRemoved fails to fire, though I'll need to make sure this doesn't do anything nasty when onWindowRemoved actually does fire properly.

I'll give some thought to your idea of adding a "force reindex" ability. I am currently working on getting tab-index-ordering working everywhere, so that the Chrome tabbar always presents tabs horizontally in the same order as they appear in the tree vertically. I'll probably be implementing something akin to a "complete reindex" function in this process, e.g. to properly initialize the tree+tabbar when the extension is first installed.

The "reset tree" function available at the bottom of the sidebar in debug mode works a bit like "force reindex" already, but it is a little too hardcore for normal use since it blows away the entire existing tree (all folders & hibernated rows are lost).

Answer
Fixed

This should be pretty much fixed in the new 2012.10.18.1 release.

Sidewise now checks for and and removes zero-child window rows in cases where Chrome doesn't fire its usual onWindowRemoved event -- as is seemingly often the case with incognito windows.

Please let me know if you're still seeing this problem after updating.