Closed Bug 16516 Opened 25 years ago Closed 25 years ago

[DOGFOOD] view sidebar not persistent on subsequent windows

Categories

(SeaMonkey :: Sidebar, defect, P1)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: paulmac, Assigned: waterson)

References

Details

(Whiteboard: [PDT-])

Attachments

(2 files)

fix to ensure 'View->Sidebar' takes effect immediately
3.12 KB, patch
Details | Diff | Splinter Review
fix to canonicalize 'chrome:' URLs
3.21 KB, patch
Details | Diff | Splinter Review 
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. ***
Status: NEW → ASSIGNED
Target Milestone: M11
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
marking verified
Status: VERIFIED → REOPENED
it's back in black.
Resolution: FIXED → ---
Summary: view sidebar not persistent → [DOGFOOD] view sidebar not persistent
To clarify, the behavior is on a second browser window that is opened up. The
pref is persistent for the initial browser window.
Whiteboard: [PDT-]
This saved feature is not for mandatory for dogfood.   Putting on PDT- radar.
Target Milestone: M11 → M12
It's no longer persistent on the initial browser window; we've regressed again.
Whiteboard: [PDT-]
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.
Priority: P3 → P1
Whiteboard: [PDT-]
DMose, we'll leave this a PDT- since you said "almost". Seriously, we have
bigger problems to deal with.
Summary: [DOGFOOD] view sidebar not persistent → [DOGFOOD] view sidebar not persistent on subsequent windows
updated bug description to current status, which is view sidebar is persistent
on the initial browser window, but is always open on subsequent windows.
Status: REOPENED → ASSIGNED
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.
Target Milestone: M12 → M13
*** 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. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fix checked in, r=hyatt
Status: RESOLVED → REOPENED
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
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
ok, marking as fixed again. paulmac, can you go kick the release team around a
bit? thanks, chris
Status: RESOLVED → VERIFIED
verified with 1/10 builds
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: