mozilla version: 0.9.4 mozilla build: 2001091506 hi. at some point in time, mozilla stopped paying attention to these settings in my ~/mozilla/default/prefs.js : user_pref("browser.toolbars.showbutton.go", true); user_pref("browser.toolbars.showbutton.print", false); user_pref("browser.toolbars.showbutton.search", false); and it stopped remembering that the 'my sidebar' pane is hidden on the side of the browser. i've hidden the 'my sidebar', and have checked the correct buttons, in the 'options' panel, to make those user_pref items to be set as they are. now, with this browser-frame, it all looks as it should, but when i open a new browser-frame, with 'File -> New Navigator Window", and when i restart mozilla, the settings aren't retained. at those points, i see the sidebar not-hidden, no 'go' button, a 'print' button, and a 'search' button, contrary to the user_pref settings. the permissions on the ~/.mozilla/default/prefs.js file, and its parent dirs, are all set to be writable by me. it's all sticky-GID'd, but i wouldn't think that would be a problem. the 'default' profile is the only one i have. i know it's still writing the prefs.js file, because it changes as i browse around. when the file changes, those user_pref items are not being modified, so it's not forgetting the settings -- it's just not paying attention to 'em. this build used to be using those user_pref settings, and remembering the state of the sidebar; i don't know when it stopped doing so. there've been a few crashes with it. hadn't noticed any other problems, though.
This is likely a corrupt-profile problem... creating a new profile should fix it.
or related to bug 86164?
Confirming. Newly created windows too have Sidebar visible and all toolbar buttons visible regardless of pref. If I enable toolbar buttons in Preferences dialog, click OK, then open Preferences again and uncheck those buttons, click OK, they disappear. But new Windows have them again as if the pref was ignored. OS: Linux Build ID: 2001100908
Our friends at bug 102134, which seems like a dupe of this, can't reproduce it. Any ideas for a reliable testcase?
Anyone seeing this on non-Linuxes? And can someone check when was it introduced? I don't see it on W2K from today's earlier build...
I also noticed that in panes that use outliner (eg. MailNews folder list and message list) show all columns ignoring prefs.
Bug 103818 seems to be a dupe of this one. This one is more complete.
if it's any help to know this, the bug stil occurs after the browser-theme is changed
marking p3 and mozilla0.9.9, can somebody try to reproduce with a recent build (i.e. around 2001-11-15)
Pushing out to mozilla1.0.1
Boris was right. my localstore.rdf had an XML-ish problem in it. the resolution: changing a bare & character to & in an <RDF:li> element in ~/.mozilla/default/localstore.rdf has resolved the problem. (also, that fix has made a recent built to work properly; with the invalid & char, mozilla wasn't paying attention to a RETURN key-press in the address-bar; should i file a new bug-report about that, even though it fixed was when i changed that & to & ?) (now, it would be nice if having a not-well-formed localstore.rdf wouldn't cause the described behavior to be exhibited, but heck, it works now.)
Which particular <RDF:li> element was this? what were its ancestors?
an xpath to the element would be: //RDF:Seq[@about="nc:urlbar-history"]/RDF:LI translated: the element's parent was an RDF:Seq element whose 'about' attribute had the value "nc:urlbar-history It looks like the parent of that RDF:Seq element was the document's root element itself; being pedantic about it, that would make it: /RDF:RDF/RDF:Seq[@about="nc:urlbar-history"]/RDF:LI the miscreant ampersand (&) character came from an HTTP GET URL like http://foo.bar.example.com/script.cgi?myfoo="qux"&yourfoo="quxtoo"
hewitt, would you care to look into this? Is URL bar somehow storing invalid data in localstore.rdf?