Closed Bug 85026 Opened 24 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: 24 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: 24 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: