mozilla not paying attention to user_prefs browser.toolbars.showbutton.* and shaded status of 'my sidebar'



17 years ago
13 years ago


(Reporter: junctionxyz, Assigned: paulkchen)



Firefox Tracking Flags

(Not tracked)




17 years ago
mozilla version: 0.9.4
mozilla build: 2001091506


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("", 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

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.

Comment 2

17 years ago
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
Ever confirmed: true
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.

Comment 8

17 years ago
if it's any help to know this, the bug stil occurs after the browser-theme is changed

Comment 9

17 years ago
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
QA Contact: sairuh → claudius

Comment 10

17 years ago
marking p3 and mozilla0.9.9, can somebody try to reproduce with a recent 
build (i.e. around 2001-11-15)
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9

Comment 11

17 years ago
Pushing out to mozilla1.0.1
Target Milestone: mozilla0.9.9 → mozilla1.0.1

Comment 12

17 years ago
Boris was right. my localstore.rdf had an XML-ish problem in it.

the resolution:
  changing a bare & character to &amp; 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 &amp; ?)

(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.)

Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Which particular <RDF:li> element was this?  what were its ancestors?

Comment 14

17 years ago
an xpath to the element would be:


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:


the miscreant ampersand (&) character came from an HTTP GET URL like"qux"&yourfoo="quxtoo"

hewitt, would you care to look into this?  Is URL bar somehow storing invalid 
data in localstore.rdf?
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.