Closed Bug 156688 Opened 20 years ago Closed 10 years ago

navigator toolbar changes do not apply if done in mailclient

Categories

(SeaMonkey :: Preferences, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: hhielscher, Unassigned)

Details

(Whiteboard: [2012 Fall Equinox])

Attachments

(1 file)

Steps to reproduce:
-open Mail&Newsgroups
-close all Navigator windows
-open Edit/Preferences
-change the displayed toolbar buttons (submenu Navigator)
-open new navigator window

what you expect:
-the toolbar buttons you unchecked do not display, the checked ones display

what you see:
-the toolbar buttons that were checked before you changed the prefs

I am using rv:1.0.0, Gecko/00200205 under Linux Mandrake 8.2.
seeing this with 2002070915/linux.
this seems to be happening:
after changing the prefs in the mail thingy, and pressing ok, it saves the new
prefs to prefs.js - but opening a new navigator window _does not reread
prefs.js_... so some cached values or variable thingie is obviously not updated.
or something. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
NICE BUG!!! Have been working the whole evening finding out how the hek those
navigator toolbar buttons preferences work and why they don't work as expected. 

I came upon this while changing mozilla versions and hacking PREFS.JS to my
liking... Anyway in mozilla 1.3a this bug is still present - and how.

Let's say I want all buttons OFF except "Go". The default is the reverse. 
Defaults are NOT saved to PREFS.JS but in my case my prefs.js reads the following: 

user_pref("browser.toolbars.showbutton.bookmarks", false);
user_pref("browser.toolbars.showbutton.go", true);
user_pref("browser.toolbars.showbutton.home", false);
user_pref("browser.toolbars.showbutton.print", false);
user_pref("browser.toolbars.showbutton.search", false);

This is all cool.

When I change PREFS.JS while having Navigator closed (you can either do that
using the prefs tool from an open mailnews menu, or just do it with a text
editor - makes no difference), and I subsequently restart navigator, my changes
are NOT reflected. 

Let's say I dont't want the GO button and I want the defaults. I remove the
lines above (or change the values) and start mozilla.
Nothing would have happened - still the GO button.

What I DID find out that if I deleted the following lines from the
LOCALSTORE.RDF file it DID work. 

So removing the following lines would FORCE Navigator to reread PREFS.JS???

<NC:persist resource="chrome://navigator/content/navigator.xul#bookmarks-button"/>
<NC:persist resource="chrome://navigator/content/navigator.xul#go-button"/>
<NC:persist resource="chrome://navigator/content/navigator.xul#search-button"/>
<NC:persist resource="chrome://navigator/content/navigator.xul#print-button"/>
<NC:persist resource="chrome://navigator/content/navigator.xul#home-button"/>

Really strange matter, I can only hope that this info will help the guy who has
invented this whole option saving/storing/reading scheme fix this bug ;-))
I attached a picture. 

- Pressing the OK button of the prefs tool would NOT get me my "Go" button -
nothing would change! 
- The only way to get my Go button and remove the rest of the buttons is:

   1) first choose the reverse situation enabling everything except Go, 
   2) closing prefs, 
   3) re-opening prefs, 
   4) applying correct settings
   5) after hitting OK it's OK for now...... ;-))
Product: Browser → Seamonkey
Assignee: bugs → prefs
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
UI for changing buttons is gone from there a long ago and changing other options is WFM here
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 SeaMonkey/2.15a1
Build identifier: 20120921003032
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.