[Affected versions]: - 45.0.2 build1 (20160407164938) - 46.0 build5 (20160421124000) - 47.0b1 (20160425205003) - 48.0a2 (2016-04-28) - 49.0a1 (2016-04-28) [Affected platforms]: - Windows 7 64-bit - Windows 10 x64 - Mac OS X 10.9.5 - Ubuntu 12.04 x32 [Steps to reproduce]: 1. Launch Firefox with a new profile 2. Go to View menu > Sidebar > Bookmarks 3. Go to Hamburger Menu > New Private Window - inspect if any sidebar is opened - close the new opened private window 4. Go to Hamburger Menu > New Window - inspect if any sidebar is opened - close the new opened window 5. Go to Hamburger Menu > New Private Window - inspect if any sidebar is opened - close the new opened private window 6. Close the Bookmarks sidebar from the main window 7. Go to Hamburger Menu > New Private Window - inspect if any sidebar is opened - close the new opened private window 8. Go to View menu > Sidebar > History 9. Go to Hamburger Menu > New Private Window - inspect if any sidebar is opened [Expected result]: - The right sidebar is properly opened regardless of the window type and the moment it was opened: main window (step 2, step 8), new window (step 4), new private window (step 3, step 5, step 9). - No sidebar is opened: in the main window (step 6), in the private window (step 7). [Actual result]: - The right sidebar is properly opened in the main window (step 2, step 8) and in the new window (step 4) - No sidebar is opened in the main window (step 6) - The private window displays: - no sidebar (step 3) - the right sidebar (Bookmarks) (step 5) - the content of the already closed sidebar (Bookmarks) with no sidebar title (step 7) - the wrong sidebar content (Bookmarks - already closed) with the right sidebar title (History) (step 9) [Regression range]: - I am not sure if this is a regression, I will check as soon as possible. [Additional notes]: - The same issue happens for the Sync Tabs Sidebar, too.

Regression window(no sidebar title (step 7), and the wrong sidebar content (Bookmarks - already closed) with the right sidebar title (History) (step 9)): ttps://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0f7bf77ccafb&tochange=e9195ed65161 Triggered by: Bug 885054

Regression from 25. evold do you want to take a look here? Or can you suggest someone to investigate? Since this issue is fairly minor and has been around for years we don't need to track though it would be nice to fix.

There are many people using Sidebar, and therefore Photon makes it easier to use Sidebar in Firefox 55 by adding the Show Sidebar button to the toolbar. Time to fix it?

I meant Firefox 57.

Bug 885054 has apparently a good use-case where the side bar should not be opened with a new private window, but having that sidebar not open automatically with a new private window is painful for extensions like tree style tab. In that case, you need the side bar to access your tabs. I am in the exact situation as described in https://github.com/piroor/treestyletab/issues/1529. My tabs are hidden and exclusively displayed in the sidebar. On every new private window, the tabs disappear. Would it be possible for to add an API for extensions that require a persistent sidebar ? Would it be otherwise possible to "reopen" the sidebar in the new window, so that no state is shared but the sidebar is still present ? I just wanted to highlight another use case than Bug 885054.

I cannot answer those questions.

I'm not sure what information, if any, about tabs we could share with a new private browsing window. Is it that you want the private browsing window to open with a particular set of tabs? Or just that the sidebar itself should be open? I've noticed this too, since I depend heavily on Tree Style Tabs, but there is a button in my toolbar to toggle hiding and showing the sidebar, so I just toggle it when I open a PBW.

Andrew, any thoughts on what the private browsing window can do about sidebars? Or can you pass this to someone else who works on PB? It looks like :billm is out or I would ask him.

:billm has moved on from MoCo. I think bug 885054 stands as an explicit UX-ish decision, with the major caveats being that the decision was made in a jetpack-extensions world which I think had a different approach to private browsing than WebExtensions and I don't think the UX team was involved. I agree that in the case of some WebExtensions like Tree Style Tabs this decision does not make sense at all. I'm moving the needinfo to :andym of the WebExtensions team to re-triage this bug in the context of WebExtensions.

Repeating comment 0, I was never able to get a sidebar to show up my opening new private windows when using Windows 10. As for extensions, we should follow along with the Firefox default and not show a sidebar unless the user explicitly chooses to activate it on the Window. For some add-ons, like a Tab Center Redux, it clearly makes sense to keep it around, but for many other add-ons it really won't. Until we are able to provide fine grained control on that for a user, we'll just have to let users do it manually with an extra click as suggested in comment 7. There's a longer term plan to give users more control over extensions in private browsing mode and ask them if they want to enable add-ons in private browsing or not. It's conceivable we could add "show a sidebar by default in private browsing mode" to that bug, however its probably low priority for that. The tracking bug for being to split extensions to between private and non-private windows is bug 1380809, if you want to change this bug to being something extension specific.

> Or just that the sidebar itself should be open? > I've noticed this too, since I depend heavily on Tree Style Tabs, but there is a button in my toolbar to toggle hiding and showing the sidebar, so I just toggle it when I open a PBW. Just that, exactly. The behavior is inconsistent between opening a link in a new (normal) window versus a new private window. We need a clear decision. Either sidebars are attached to windows, and do not open in new windows of any kind, or sidebars are part of the browser UI, and should open identically in every new window. Once the behavior is consistent, we can request an update to the WebExt interface to toggle it. Or maybe we could just let extensions decide how their sidebars should behave in new windows. A {never, inherit, always} property maybe ? "inherit" would be relative to the window where the link was clicked, or to the previous session for the first window.