Overview Description: View Sidebar works for the current session but is not persistent. Steps to Reproduce: 1) Launch apprunner 2) If sidebar is open, close it with View Sidebar. (If sidebar is closed, open it with view sidebar) 3) Shutdown and re-start. Actual Results: The state at shutdown with not be saved if you had toggled it in the last session. If it was open the last time you launched, it will be open again. Similarly, if you had it closed at previous launch, it will be closed again. Expected Results: The state at shutdown should be saved. Found on 101508 builds, all platforms.

is this different from the splitter problem, slamm?

Yes, this is differenct than the splitter problem. When you hide the sidebar with "View / Sidebar" it sets the "hidden" attribute to "true" on the splitter and on the sibling box. I was guessing that persistence was broken. I went to try this out on my build from today, but there is no apprunner executable in the build directory. What is up with that?

I think it is called mozilla.exe now?

Right! I am so stupid!

this is working on Linux as of 10/22 morning builds. We will verify on other platforms before marking fixed.

Dunno what's different about your build, but it's not working on my 10/22 Linux build. Remove your localstore.rdf to ensure a clean start, start apprunner, do view->sidebar, the sidebar goes away, do file->quit, then run apprunner again: the sidebar is back.

This is busted for me too in my linux build from today. My windows build from yesterday is also busted.

Okay, I'm wrong. Turns out there was a renegade apprunner instance running in the background so I was never really fully shutting down. Maybe this could be a feature :-)

*** Bug 17161 has been marked as a duplicate of this bug. ***

Okay, this time it really does look fixed with 10/27 builds. Both Linux and Windows hold their sidebar state persistent after a re-start.

marking verified

it's back in black.

To clarify, the behavior is on a second browser window that is opened up. The pref is persistent for the initial browser window.

This saved feature is not for mandatory for dogfood. Putting on PDT- radar.

It's no longer persistent on the initial browser window; we've regressed again.

Not only is this not persistent across logins, even opening a new browser window doesn't honor this setting. For users who use do lots of things in various different brower windows, having to constantly close the sidebar is quite irritating. It's almost enough to make me want to stay with Communicator until this gets fixed. Continuing to ship with such a basic usability issue as this seems like it's gonna drive away users. I'd like to ask the PDT team to reconsider this bug.

DMose, we'll leave this a PDT- since you said "almost". Seriously, we have bigger problems to deal with.

updated bug description to current status, which is view sidebar is persistent on the initial browser window, but is always open on subsequent windows.

This is (now) happening because of inconsistent use of 'chrome:' URLs; e.g., chrome://navigator/content/ vs. chrome://navigator/content/navigator.xul Both of which resolve to the same thing. The former is used at browser startup, and is hardcoded into the product somewhere. The latter is used in the "open new window" handler (and other places). So, what needs to happen is we need to decide which we want to use, and the consistently apply it. I'd suggest we stick with the former; i.e., without the explicit "navigator.xul". cc'ing law and hyatt, who may have opinions.

I've found "chrome://navigator/content/navigator.xul" in... tasksOverlay.js navigator.js nsContextMenu.js openLocation.js Unilaterally changing these to "chrome://navigator/content/" seems to fix the problem.

slamm: please take a look at the attached patch... 1. Removed unnecessary try block in sidebarOverlayInit() 2. Add immediate 'persist' call to sidebarShowHide() This ensures that choice of "view" will take effect on the very next window that's opened.

The patch looks good to me.

After talking with slamm, I think that the correct way to fix this is to consistently use "chrome://navigator/content/navigator.xul", rather than the magical default stuff. It just makes stuff clearer. Comments?

After talking to hyatt, we agreed to make the chrome cache and the persistence stuff smart enough to collapse both cases to the same thing.

*** Bug 12575 has been marked as a duplicate of this bug. ***

This is fun: close the sidebar in a browser window, open a new browser window, and watch the first window as the second launches. The sidebar will open again in the first window while the second window draws itself, and then close again. That's just wrong, regardless of whether or not the second window starts with the sidebar closed (it doesn't). Tested with: 1999-12-09-08-M12 nightly binary on Windows NT 4.0sp3.

*** Bug 21174 has been marked as a duplicate of this bug. ***

*** Bug 18503 has been marked as a duplicate of this bug. ***

*** Bug 18503 has been marked as a duplicate of this bug. ***

fix checked in, r=hyatt

Still a few problems with this. Not sure if you want a new bug. Scenario 1: Create a new profile. Close Sidebar with View - Sidebar. Shut down and re-launch. Sidebar is closed! Perfect. Scenario 2: Create a new profile. Close Sidebar with View - Sidebar. Open new navigator window. Sidebar is open. Damn! Same behavior after shutdown and re-start. Scenario 3: Create a new profile. Close Sidebar with View - Sidebar. Open new navigator window. Sidebar is open. Close with view - sidebar. All subsequent windows will have sidebar closed, including after a re-start. Perfect. So, to actually make it so you never see sidebar again, you have to close the sidebar using view sidebar on the initial window, and then open a new window and close it again with view sidebar. Did a marketing person put you up to this? Using a linux 1/6 build

Damn, I thought (2) and (3) were working. I'll look at it some more.

Ok, I am not seeing (2) on Win32. Maybe a [PP] issue? Could you try it out on Win32 and Mac?

Yes, it looks okay on windows. Checking on Mac now. Anything you want me to look at on Unix to help investigate?

Ok, in the build that I just pulled, Unix -is- working correctly. Could somebody with a hand-built, current-as-of-tree-closure-this-morning build please try this on Linux? I wouldn't be surprised if the release team spit out bits that were pulled from a timestamp yesterday or last night. Stranger things have happened.

I just tried it on an optimized updated-and-built-this-morning tree ... and sure enough, the problem is gone, and the sidebar state is remembered. It isn't remembered on this morning's mozilla build on sweetlou. Somehow, the sweetlou release build doesn't seem to have gotten the fix.

ok, marking as fixed again. paulmac, can you go kick the release team around a bit? thanks, chris

verified with 1/10 builds