I haven't been able to locate a specific file like you describe in C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default which would do the trick. Even if there is one, we don't really have any guarantee that Chrome would automatically and properly load data from such a file if it was modified outside of Chrome; for example, how would it notify the extension that its settings data has been changed and the extension needs to address this? 

It looks like there is actually a Chrome API to do synchronization of extension data between signed-in Chrome instances: http://developer.chrome.com/extensions/storage.html

Unfortunately I am concerned about the storage limits that it imposes -- 4K per setting and 100K overall limit. In the case of Sidewise that could definitely become a major obstacle: at the moment I have 30 pages in my sidebar, and my JSONified exported extension data weighs in at 30K. While this could be greatly reduced in size by using some kind of compression on the data, the problem will just get worse as I implement the Recently Closed pane, per-tab Tree Style Histories, etc.

By contrast the local storage limit for extension data is 5MB per extension. So in all likelihood, the final solution for sync won't be able to use the Chrome storage sync API, other than perhaps for triggering notifications to other synchronizing Chrome instances to go fetch the actual extension data from some third-party location. 

Unfortunately Chrome gives us no way to differentiate between window-focus and window-raise occurrences; there is a "chrome.windows.onFocusChanged" event and that's it.

Similarly, Chrome gives us no way to just raise a window without also focusing it. I've submitted a Chrome bug to fix this specific issue. If Chrome implemented this, then if I understand your problem correctly, I believe the problem would be fixed -- when Sidewise needed to make the sidebar visible it could just raise the sidebar instead of raise+focusing it. This would also alleviate a few other issues related to the fact we can't raise the sidebar without also focusing it.

So for now your best bet is probably to go star that issue for a little more visibility :) 

For what it's worth, on my system I am using an Autohotkey script that you might call "XScroll": it allows the mouse wheel to scroll whatever window/control the pointer is over without switching focus. I used XMouse for a long time but have found the XScroll behavior more to my liking. Let me know if you are interested in this.

Those numbers correspond to window numbers in previous sessions -- e.g. "Last Session 2" would have been the 2nd of 2 (or more) windows that was open in a previous sesson. Of course once you start having the accumulation of multiple previous sessions it all gets a bit confusing :D

Very strange indeed. I'll give this some thought ... I have another fix in the next release which should remove "0 page" window entries from the tree in cases where Chrome fails to inform us that a window was closed (but still removed all of its tabs), I'll take another look at that to see if it might catch this problem. Haven't been able to reproduce it yet though.

Regarding the Last Session entries, you can just close those, or try turning off the "Remember open tabs between browser sessions" option. The current behavior is basically the expected behavior right now, but as soon as I get a "Recently Closed" sidebar pane implemented (the next major planned feature), this accumulation of "Last Session" windows will go away; instead we'll just move older "Last Session" stuff into the "Recently Closed" list.

Implementing the full text search should be pretty straightforward -- Chrome lets an extension run custom Javascript on-demand on any/all tabs, so I should be able to just do the searching that way, then pass back the matches to the extension.

I think it might be nice to also show a 1 or 2 line snippet of the text that matched below the matched-row entry in the results list. Still considering this.

That's very weird... I'm wondering if it has something to do with the presence of pinned tabs. If you unpin those and restart, does it clear out the yellow "0 page" window(s)? If you try this let me know the results.

I have a couple fixes relating to pinned tabs coming up in the next release. I'll do some tests here before then to see if I can reproduce what you're seeing.

Good ideas. I think I'll just stick a couple checkboxes below the search box that appear when something is entered in the search box:

[x] Open pages only [x] Search within pages

Oh that's interesting. On Windows, a single click on a row in the sidebar both activates the sidebar and sends that click through to do row-focus as well.

Marking this as planned -- should not be hard at all to implement "focus row on mouse hover" as an option.

---

Implemented as an advanced option (default off), along with a setting to specify a custom delay before doing the focus after hovering a given row (default 150ms). This feature should be present in the next release, due by end of month.

The "Create new tab" button has been added per your request and will be appearing in the next release, due out by end of month. Additionally you will be able to double-click in the empty space below the page tree to create a new tab in the current window. And there is a new option "Creating a new tab from the sidebar opens" where you can choose "New Tab page", "your homepage", "google.com", or "blank tab" when you create a new tab via these methods.

I'm going to leave this issue marked as PLANNED until I address the "retain previous window positions" request as well.

As of today I can go to Trello.com, log in, and make new cards without Sidewise crashing anymore. I also rolled my version of Sidewise back to the last release version (the one you'd be running) and did not experience the crash.

So it was probably a problem in either Chrome or Trello.com that has now gotten fixed. So I'm calling this FIXED for now.

If you could go in and check to see if you are still crashing and report back here, that would be helpful.