OK, I understand.

Unfortunately, since Chrome does not offer us a real sidebar API for extensions to use, Sidewise "fakes it" by opening a second Chrome window and sizing/positioning it to where we want the sidebar. The consequence of this is that we can't have the primary Chrome window be maximized on one display, leading to the scrollbar displacement problem.

So at this time there are really only a couple options:

- Make Sidewise undocked and underneath the primary Chrome window, then switch to it when you want it.

- Put the Sidewise sidebar onto a second adjacent monitor and uncheck the 'allow Sidewise to unmaximize the dock window' option. 


One possible other solution is to add a feature to Sidewise where it forces the primary Chrome window to essentially be larger than the display it is on, so that its window borders go off the edge of the display thus mimicking a maximized window more closely. I'll give this some thought, but I have a feeling that Chrome may not allow this -- it may just snap the window's edges back to fit within the confines of the display.

What hotkeys do you use for these functions?

Are there any other ways to perform the "new child tab" function that you think should be supported?

Good idea. I'm holding on implementing keyboard shortcuts until Chrome team moves the Keybinding API out of the experimental phase; without this Sidewise would be unable to detect keypresses from certain tabs which would be inconsistent and annoying.

Once they do this will probably be the first keybinding to go in.

I wasn't able to reproduce this bug on Win7/Chrome m21, but I have made a change which I believe will proactively address it on your system: when Sidewise tries to reassociate an opening tab with some hibernated tab in the tree it will no longer require the "pinned" state of the two to be the same.

My suspicion is that the build of Chromium you are using isn't reporting the "pinned" state accurately for tabs as they are opened up. By ignoring "pinned" during the association process, this should likely correct the problem.

I'll update here when this change is released, and if you can test at that point to make sure the fix worked that would be great.

You make a good argument. My main concern with putting the Close menu item at the top was the possibility of accidental clicks on that first menu item, which would be a rather destructive accident :)

I'm considering waiting to make the change you suggest until after the Recently Closed sidebar pane is implemented, which would make it much easier to revert such a misclick.

To clarify, is your issue that the sidebar is taking up the right edge of the screen and therefore the dock window's scrollbar is located to the left of the sidebar?

If so, one thing that might help out is to dock the sidebar to the left of the dock window instead.