I believe ComObjCreate() is unique to AHK_L (not in the older AHK build). Are you running AHK_L? http://l.autohotkey.net/

Essentially, Sidewise requires this level of access because it has to communicate with each individual tab/page for various pieces of information that are used to construct and display the tree's contents. 

For example, Sidewise uses the referrer (opening page's url) of each page to help it uniquely identify which page goes with which row in the tree (e.g. during session restore). Currently, this information can only be obtained in Chrome by asking each page for it. Similarly, Sidewise needs to communicate with each page to ensure that we have the correct page titles and favicons at all times.

Other features such as the Youtube timer also rely on this kind of page communication. And future features, such as "search text on all pages" from the sidebar, will require this permission as well.

The real problem, from an extension developer's perspective, is a lack of fine-grained control over what an extension needs to see on a page. Currently, it's basically an all-or-nothing affair. If I need one bit of information from a page, I have to request permission to see the whole page.

I will give some thought as to whether page-access could be made into an optional permission. Having it disabled would definitely impact some pretty core aspects of how Sidewise works, and I'm not sure the penalties in tree functionality/accuracy would be worth it. I suspect users might find the limitations it introduces to be annoying or confusing.

I will be open sourcing the Sidewise codebase in the not too distant future, at which point other developers can independently verify that Sidewise does not do anything bad with its access to these permissions.

Until then, the best I can offer you is my personal promise that Sidewise does not, and never will read or collect any of your personal information without your explicit permission.

Currently this should be possible by clicking Chrome's "tools" button (the three-horizontal-lines icon at the far right of the address bar) then choosing Exit. When you restart later, any windows that were open at the time of exit should be preserved. This is also assuming you have the "Remember open tabs between browser sessions" option turned on.

The next major feature I'm planning on is a "Recently closed" sidebar pane. Once this is implemented, it should be possible to find all previously closed windows there just as they were, regardless of how you closed the windows/Chrome previously.

If Chrome crashes, it should also remember all the windows that were previously open, similarly to when the Exit method is used.

Currently this should be possible by clicking Chrome's "tools" button (the three-horizontal-lines icon at the far right of the address bar) then choosing Exit. When you restart later, any windows that were open at the time of exit should be preserved. This is also assuming you have the "Remember open tabs between browser sessions" option turned on.

The next major feature I'm planning on is a "Recently closed" sidebar pane. Once this is implemented, it should be possible to find all previously closed windows there just as they were, regardless of how you closed the windows/Chrome previously.

I'm afraid "reset tree" permanently deletes and rebuilds the tree from scratch.

I apologize for not making this more clear. I'll add a confirmation box when you click "reset tree" in the near future to help avoid unintended consequences.

I'm also planning to add some sort of "recover last version of tree" button to the options page for cases where something goes wrong and the user wants to restore things to an earlier point in time.

I'm afraid "reset tree" permanently deletes and rebuilds the tree from scratch.

I apologize for not making this more clear. I'll add a confirmation box when you click "reset tree" in the near future to help avoid unintended consequences.

• Add the video-driver-causing-crash issue/solution to the upcoming FAQ
• Look for additional ways of reliably acquiring the correct favicon for sites like msdn.microsoft.com

• Add the video-driver-causing-crash issues to the FAQ
• Look for additional ways of reliably acquiring the correct favicon for sites like msdn.microsoft.com

Well glad to hear the crashes are preventable, at least. In my case, I also had the latest (ATI) video drivers, but the crashes didn't stop until I uninstalled and reinstalled the same version of those drivers. My best guess is that Chrome somehow gets confused about which GPU features the video driver supports and this ends up inducing crashes in this way. Might be worth a shot.

I'll look into the favicon issue separately. Favicons have been a persistent sore spot for Sidewise due to how Chrome handles favicons (in a word, poorly). I actually have it looking for the favicon in four different places now (chrome://favicon, Google's S2 favicon cache, in the <head> of the document, and just using what Chrome normally reports to extensions via chrome.tabs.get()).

In the case of msdn.microsoft.com, the favicon is not present in either the <head> or from chrome.tabs.get() and that appears to be why we're winding up with the "file" favicon. I'll continue to look for viable alternative solutions.