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

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect, P3)

Description

[sc]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is likely a corrupt-profile problem... creating a new profile should fix it.

Comment 2

[R.K.Aa.]

or related to bug 86164?

Comment 3

[Aleksander Adamowski]

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

Comment 4

[Aleksander Adamowski]

Our friends at bug 102134, which seems like a dupe of this, can't reproduce it.
Any ideas for a reliable testcase?

Comment 5

[Aleksander Adamowski]

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

Comment 6

[Aleksander Adamowski]

I also noticed that in panes that use outliner (eg. MailNews folder list and
message list) show all columns ignoring prefs.

Comment 7

[Aleksander Adamowski]

Bug 103818 seems to be a dupe of this one. This one is more complete.

Comment 8

[sc]

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

Comment 9

[Asa Dotzler [:asa]]

->apps

Comment 10

[Paul Chen]

marking p3 and mozilla0.9.9, can somebody try to reproduce with a recent 
build (i.e. around 2001-11-15)

Comment 11

[Paul Chen]

Pushing out to mozilla1.0.1

Comment 12

[sc]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

Which particular <RDF:li> element was this?  what were its ancestors?

Comment 14

[sc]

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"

Comment 15

[Boris Zbarsky [:bzbarsky]]

hewitt, would you care to look into this?  Is URL bar somehow storing invalid 
data in localstore.rdf?