Closed Bug 85026 Opened 23 years ago Closed 15 years ago

view->sidebar setting not persisted (can't permanently disable sidebar)

Categories

(SeaMonkey :: Sidebar, defect)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: tachysx, Unassigned)

References

Details

(Keywords: meta, Whiteboard: [br])

Attachments

(1 file)

Renaming this localstore.rdf file solved problem
39.68 KB, text/rdf
Details
Whenever I open Mozilla or open a new window the sidebar is always open. It should be closed by default.
There is a preference setting for this, if I recall correctly.
wfm 2001060920 Disabling the sidebar (F9 of view -> my sidebar) and opening a new window or relaunching mozilla doesn't make it appear
Not in the Mac OS Version Got the latest nightly build. I doesn't matter what I do to F9 View > MySidebar Whenever I open a new window or launch Mozilla, the taskbar is open
I closed the sidebar, then I re-launched a new browser and the sidebar was closed... I will retry on trunk build...
I'm using today's trunk builds and I after I close the sidebar and relaunch a new window, I see it closed.. please try again on latest builds.
twalker, do you see this on Mac trunk builds from today? please check, thanks.
Remember I have only seen this happen on the Mac Version I know this does not happen on Windows I playing with the latest nightly This happens no matter how I install it But if I delete the component registry this stops It just builds a new registry and this stops happening
BTW, how can I found out what all those components do?
*** Bug 85973 has been marked as a duplicate of this bug. ***
We received lots of PR1 feedback about this, on all platforms: "I close MySidebar, and the next time I start it pops it open again. I want the stupid thing to go away forever!!! How do I make it so that netscape starts with mysidebar closed by default?" "Please help me get rid of those awfull sidebar tabs They take away from viewing area and my people simply do not use netscape 6 because of them. If there is a way of removing them please advise." "How can I get rid of this stupid sidebar. It takes up too much space and there does not seem to be the option of permenantly getting rid of it." "You need to make it easy to turn My Sidebar OFF and have the program remember it. I am about to UNinstall Netscape 6.1 and revert to 4.76 just to get rid of the damn thing." "How do I get rid of the sidebar. I don't want it, I remove it from the view menu, then it pops straight back again. I double click on the option to "minimize" it to the side, and it pops back up again. I'm really annoyed with the sidebar. Please help." "How do you disable the my sidebar. I know how to get rid of it, but every time I open a new window up it pops again. Also everytime a new window opens it is small." "Each time I launch Netscape 6, I have to remove the Sidebar from my view. I have attempted to add tabs to it from the web, but it doesn't show the tabs so it is absolutely useless. So I uncheck it from the View menu, but it reappears every time I run Netscape!!" "I *hate* "my sidebar". I wish there was a way to remove it for *good*. When I open a page I want the page - all of it. - not 2/3s plus "my side bar" - I hate having to go to the toolbar to close *everytime* I open a window. Please. please, please tell me how to set up my preferences so I don't have to look at this useless non-optional feature!!!!!!" "Can do View>MySidebar and un check it. but it does not remember this setting. Have to close it each time which is a hassel if you are using multiple windows. Need to be able to turn it off and on in a pref." "the side bar is VERY ignoring and i wish to take it off, but it pops back up even when i turn it off from view. how do i turn it off!!!!!!! " "taking up space on my screen. I go to View and uncheck it. It disappears for 4 or 5 screens and then reappears. If I go back to VIEW it is checked again." "On a website, click on a link, when the link new page is loaded My Sidebar appears again, even though I have shut it off in the View menu. It should not do this, if I turn it off that means I don't want to see it, at all." And that's just a sampling. There's obviously a problem here that we need to investigate. I'm having trouble reproducing; sujay, sarah, claudius, john, can any of you?
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac System 9.x → All
Hardware: Macintosh → All
Whiteboard: [br]
blake, this is the same song I've been singing for at least two years now. namely, that View-->Sidebar-->go the hell away. Needs to stick better. We pop it open on all sorts of occasions that drive people crazy. Just chatted w/ jrgm and he thinks that people may be seeing the sidebar open on a new window when they previously turned it off in the View menu or minimized it. That would be a huge bug and a regression.
Yes, I know that it pops open in too many cases, but I think the number of complaints about this seems to suggest what John said. Few people said anything about search results, etc., they just said that they turned it off, and it was suddenly open again in a new window.
In the comments above, it's not entirely clear what the problem is. It could be: 1) users are having difficulty in discovering how to disable and/or collapse the sidebar. That would be a UI/UE design issue. 2) sidebar comes back for a search result, even though user had de-selected 'View->My Sidebar' (what claudius notes). I agree with claudius: if I've disabled the sidebar (de-select 'View->My sidebar'), then I don't want it coming back. [yes, you can set a pref in one of the panels, but many users never open preferences]. 3) sidebar state is not being persisted, perhaps due to a leak. 4) others? I've installed the beta from the Netscape site on Mac, and run with a new profile and with a migrated profile, and I can't find any example of (3). (2) is "by design", and (1) is for UE folks to ponder over. I will note a scenario where it may appear to users that even though they have collapsed or disabled the sidebar in the current window, it will appear in new windows. i) launch mozilla ii) collapse the sidebar iii) open a new window (sidebar appears as collapsed). iv) in the new window, expand the sidebar. v) close the new window vi) in the original window, where the sidebar is still collapsed, launch a new window vii) the new window appears with the sidebar expanded. Huh? This is because it is the last transition in state that determines what the state will be for new windows, or for the state at the next restart.
Keywords: regression
Summary: Sidebar should not be open by default → view->sidebar setting not persisted (can't permanently disable sidebar)
i've tested this on mac and windows. Open browser window toggle sidebar menu item exit browser start up no sidebar same thing for new windows. Can't reproduce. Please tell me a testcase
responding to john 1)there is a pref to turn off sidebar opening on search 2)the window has the sidebar in the state the menu item is lasts toggled. I think this is the correct behavior since they made a point to turn it off or on.
1) Yep, I knew there was a pref (see above), but that's a side issue. 2) I agree that the current behaviour is correct. I was just noting it as a possible scenario where a user might interpret it the wrong way.
does this mean i can mark this worksforme without pissing people off?
Downloaded the latest mac nightly, this doesn't happen anymore. As for the issue of searches causing the sidebar to open. That is addressed in Bug 56969
marking worksforme
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
This problem is back in Macintosh Mozilla 9.2
This bug back in Mac Mozilla 9.2
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Yes, lots of complaints on Slashdot (specifically about the sidebar showing up even after you hid it, not that it came up on search results, etc...) Plus I saw this firsthand on Ben's laptop. Simply: he starting Navigator, closed the sidebar, closed Navigator, restarted, and the sidebar was open. I think we should try to fix this for rtm...
Keywords: nsbeta1
*** Bug 88696 has been marked as a duplicate of this bug. ***
nav triage team: Marking nsbeta1+, p3, and mozilla1.0 Until we can get a reproducible test case, pushing out to mozilla1.0. This isn't to say that the bug doesn't exist or isn't important, but with what seems half of the people running into this and half not, we need more info on this.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla1.0
I disagree, I think that means it just warrants more investigation in this timeframe... sujay, are you able to reproduce this on any platform with a new profile?
Keywords: nsBranch
->sgehani
Assignee: matt → sgehani
Status: REOPENED → NEW
Using build 2001090303 on Win95osr1 when I open a composer page the sidebar isn't there so I go to View and select my sidebar and it appears. When I open another composer page the sidebar isn't there and I expect it to be. On the previous builds I have been using once I made the selection for my sidebar it carried over to all other composer pages I would open. Let me know if you want me to write up a bug as I don't want to file a dup.
Blocks: 99227
Nobody seems to be complaining much about that scenario ;-), although the underlying cause could be the same. I don't see enough evidence here that this is a major problem, worth further time/risk this late in the release cycle. nsbranch-, but would reconsider if someone provides a reproducible case that is likely the cause of many complaints which otherwise could be explained by poor UI, search policy, Bug 56969, etc
Keywords: nsbranch → nsbranch-
(Note that there is a known problem (likely a leak) that is preventing persistence from working once you have brought up the autocomplete dropdown in the urlbar. But that is bug 96393).
No longer blocks: 99227
I think fixing bug 49166 might be of great help to people who complain about the sidebar.
Blocks: 107067
Keywords: nsbranch-
Taking for mozilla0.9.8.
Target Milestone: mozilla1.0 → mozilla0.9.8
hi, I hope I'm not doing anything wrong by posting here -- I'm new to mozilla (mozilla-0.9.2.1-2) & linux (redhat 7.2). I bumped into this bug report when I couldn't make my sidebar disappear. Then following that I also couldn't save the mozilla window size (i.e. after closing & opening it, it would never preserve the last window size). Two unrelated problems... it seems. Then it turns out I get this message when starting mozilla from command line (like so: mozilla -width 800 height 800 ... just another attempt of mine to fix the window size problem): ** XML Error in file 'file:///home/me/.mozilla/default/kibqahgu.slt/localstore.rdf', Line Number: 24, Col Number: 20, Description: not well-formed*** I look at the above file and find that the named line appereantly has a corrupted history item (i.e. a page in my history, except that the URL seemed corked up). I removed those two history items and after that I could remove the sidebar (permanently!:) AND mozilla would preserve the window size upon close & open. That's all I can tell you... seems magic to me. :) Unfortunatly I don't have a sample of the "corrupted history" item in localstore.rdf anymore... it was just a lucky shot. Hope that helps & good luck -- I like mozilla, Philip p.s.: I spend hours on the above... :j whatever it is, fix it please. :)
The problem is still there: - Start Mozilla - Turn Sidebar off: View-->Sidebar or F9 - Close Mozilla - Start Mozilla - Sidebar still there In addition the window size is not persistent. All exactly the same as Philip described. Clearing history does not help me. The sidebar is also always present in the Mail program, even if have it turned off in the browser!
P.S. I am using nightly trunk build 2001112003
L.M. de Vries : can you go into your profile and rename 'localstore.rdf' to 'whatever.rdf' and try to see if that fixes your problem. If it does can you update here, and possibly attach that localstore.rdf to this bug. (Alternatively, just start mozilla with 'mozilla -console' [on win32/linux] and see if you see a message similar to the one above about "XML Error in file"). I have a bug around somewhere about automatically deleting a corrupted localstore.rdf and I'm just wondering if it is the actual localstore file that is giving you a problem.
*** Bug 111378 has been marked as a duplicate of this bug. ***
Yes! That worked! It also solved some other problems that I was having lately: - After typing in a URL in the address bar it would not load - Searching in the sidebar did not work Thanks John, Manuel de Vries P.S. I will attach the localstore.rdf that caused the problem to this bug
Sidebar kept showing up. Removing this file from my profile solved the problem
Um, are you sure that attachment is what was in localstore.rdf on your disk? Because that attachment is 38KB of nulls. I can't imagine how that could ever be written into localstore.rdf (but never say never :-]).
Yes, I am very sure that that is the "correct" file. I do download the latest trunk build almost daily, and sometimes it does crash ;) This corruption is probably the result of one of those crashes. I have no idea how I received this 38KB of nothingness :) Well, at least that explains my problems. P.S. No, I never edited/copied this file before. I was not aware of its existence.
I just renamed my localstore.rdf and relaunched Mozilla. Sidebar setting works fine now. Here's the interesting part: the bad localstore.rdf file was LF-delimited, and the newly-created file was CRLF-delimited. Looking elsewhere on my hard drive I found one from May that was in the US subfolder of my .slt folder and was CR-delimited, and three other copies of localstore.rdf in the 0.9.6 Mozilla Folder that were CRLF delimited. Could an LF-delimited localstore.pdf file be the problem? I've copied the bad and good localstore files to http://xi6.com/mozilla/ so that the experts can figure out what's wrong.
Thanks for posting those localstore.rdf files. The LF vs. CRLF issue isn't a problem. (It just falls out of two different ways in which a localstore.rdf is placed in your profile, but either form of line ending is parseable). The 'bad' version of localstore.rdf is corrupted in the same way as bug 99235, where there is an embedded ^C in one of the URLs [which is an illegal character in XML, and parsing barfs if it finds that in a file]. Specifically this line: <RDF:li>http://strangecandy.keenspace.com</RDF:li> The "front-end" fix for bug 99235 was landed Oct 25, so 0.9.6 should not be corruptible by pasting bad content into the urlbar anymore. There is another bug (bug 99236) to delete localstore.rdf if the parse fails and create a new default localstore.rdf in its place. I've threatened to write a patch for that but haven't done so yet. At any rate, that would defend against the other bad localstore.rdf with random junk in it (although it would be nice if we could figure out how that happened in the first place).
I suppose what happened may have been due to UI confusion between Mac and Windows I could possibly have typed a ^C to do a "copy" from the URL bar instead of Command-C. That's as plausible of a scenario as I can think of.
I just thought of something else much more plausible. The ENTER key on the Macintosh generates an 0x03 (control-C) character code. Maybe I tried to go to a typed-in URL by hitting the ENTER key instead of the RETURN key. When that didn't work, I then hit the RETURN key and it went to the page, but the 0x03 could have ended up in localstore.rdf afterward. (FWIW, I've noticed that alerts in Mozilla-Mac are unresponsive to the ENTER key.)
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Status summary: Bug 111723 fixes the problem that let the control-C get into my own localstore.rdf file. Bug 99235 prevents URLs with control characters from getting stored in the history, even when pasting control characters into the URL bar. When bug 99236 is fixed, an already corrupted localstore.rdf file will be automatically deleted. I suppose there really should be a preventative patch to prevent control characters from getting into .rdf files from any source, not just urlbar-history. FWIW, looking at attachment 48991 [details] [diff] [review], a more defensive place to patch bug 99235 would have been in RDF MakeSeq. But it's not worth the effort to change this now, when patching bug 99236 will automatically fix things up with a minor data loss of user preferences. So I guess this bug now only depends on bug 99236. This (an already corrupted localstore.rdf file) should be the only remaining situation in which bug 85026 will occur.
Depends on: 99236
We'll use this meta bug to track the dependency on bug 99236.
Keywords: meta
Target Milestone: mozilla0.9.9 → mozilla1.0
How can this be both meta and a regression?
Keywords: regression
Target Milestone: mozilla1.0 → mozilla1.2alpha
This one is back again in the 2004262109 build, under Win98SE at least. If I'm looking at a Goodle search output in a tab, and close the sidebar, it opens again as soon as I follow a link and the link opens in that same tab. This is regressed since 1.8a, where this behavior was not seen. Since I've never set a "sidebar preference" in my life, just dragged or "X"ed the sidebar closed, this is a regressed bug compared to prior behavior. Point of fact is, I cannot find a way to keep the sidebar closed at all, just minimally narrow. If I close it completely, it opens the next time the tab contents are changed. [This bug has been around since 2001, why is it still marked "NEW"?]
Product: Browser → Seamonkey
Assignee: samir_bugzilla → nobody
Priority: P3 → --
QA Contact: sujay → sidebar
Target Milestone: mozilla1.2alpha → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → EXPIRED
Ever confirmed: true
Closing as WORKSFORME. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110813 SeaMonkey/2.5a1
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: