81093 - Opening pref panel for the first time unchecks toolbar buttons not in view

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P2)

Description

[Claudius Gayle]

***Overview Description: 

	In the prefs window under the Navigator panel, unchecking the box to show/hide
the bookmarks button for the first time will cause all of the other buttons NOT in view
to become unchecked as well.
	On my mac since only Bookmarks and Go(unchecked by default) are visible w/o
scrolling every single optional button in the chrome was hidden.

***Steps to Reproduce: 
1) If you've never unchecked the 'bookmarks' button try it now, otherwise create new
    profile.
2) Edit|Preferences|Navigator.
3) Under "Select the buttons you want to see in the toolbar", uncheck 'Bookmarks'
4) Click 'OK'

***Actual Results: 

All buttons that aren't initially visible in that preference panel treeview become unchecked.
	
***Expected Results: 

Just the bookmarks button should go away.

***Build Date & Platform Info:
 
20010515 builds on all platforms

***Additional Information:

This only happens the first time (hence the new profile). afterwards you have to go back
and check them all back on individually. I tried this with the 'home' button and got the same
result. I'll bet this is a tree bug but where else are there checkboxes on trees?

Comment 1

[Claudius Gayle]

keywords

Comment 2

[sairuh (rarely reading bugmail)]

cannot repro using 2001.05.16.12 bits. marking wfm! mebbe you got a Bad Set of
Builds...?

Comment 3

[Claudius Gayle]

Todd, this bug is the bug to which I was referring.
I definitely saw it on all platforms at the time.

I can now reproduce it again with the 20010531 builds on all platforms.

Sarah, I've had the most repro success unchecking 'Bookmarks' and then
watching for 'toolbar search' or 'shop' to go away.

Before any Mozilla types get on me btw this still affects buttons in Moz
like 'search' and 'print' and is a core problem.

Comment 4

[Viswanath Ramachandran]

severity: its pretty bad if your chrome items like print button disappear
unintentionally. 

Comment 5

[Viswanath Ramachandran]

nav+pdt: since frequency of this problem is not documented, moving to early 
m0.9.3 instead. we shd see if beta feedback reports this as a problem. 

Comment 6

[Rafael Ebron (:rebron)]

Just to add to this, I lose personal toolbar buttons, search and shop and main
toolbar buttons search and print, after switching search engines via prefs,
navigator, internet search.  

And also, around 5/29-6/3, lost those same buttons when I cleared my location
bar (and history?) and after I hit okay, those buttons disappeared.  Can't seem
to do it again though with latest builds.  

Comment 7

[Claudius Gayle]

bells, whistles, whatever. I feel dumb for not seeing this. With a 2001060509 branch
build (this bug existed before the branch so i imagine the trunk suffers similarily) just
opening preferences(navigator tab selected by default) for the first time with a new profile
(this would included newly migrated profiles) will cause all of the toolbar buttons whose
checkboxes are not already in view to become unchecked after pressing okay.

To repro:
1. Launch with a new profile
2. Edit preferences. Naviagtor panel should already be selected.
3. Click 'OK'.

Results:
Checkboxes for buttons which were not visible under the "Select the buttons you want to see
in the toolbars" become unchecked and their corresponding buttons immediatley disappear
in the browser chrome.

reassinging to vishy, upping severity to critical, and resetting TM to null, that should trigger
all the right radar.

Comment 8

[Claudius Gayle]

remember this only happens the FIRST TIME.

Comment 9

[Todd Pringle]

Vishy, I think we need to move this back into the stop ship pile - 0.9.2.

Comment 10

[matt]

Claudius comments outline this bug.
Do not scroll the list.  Even if you scroll the list
you will make the buttons appear.

we have the correct pref in the file.
pref("browser.toolbars.showbutton.search",  true);

So let me outline why this should be a stop ship:
Any new profile who opens prefs that does not scroll the buttons list
and then hits OK will have some of these buttons vanish.  That makes
for most of the buttons on the toolbar as well as the search button.

Comment 11

[matt]

.

Comment 12

[matt]

back to vishy since hyatt thought this was a xbl problem but apparently it since 
it only happens on the first go around he thinks it's not.  
More investigation by check boxes out of tree.

Comment 13

[Paul Chen]

nav triage team:

Marking nsbeta1+ and mozilla0.9.3

Comment 14

[matt]

0.9.3?   Triage team do you understand the repercussions of this bug?

New user makes profile
New user opens prefs.
New user does some actions in prefs
New user clicks ok
New user has search button disappear along with may other buttons that are not 
visible in the button list including on Netcape builds those super secret 
netscape.com buttons that i can't mention in bugzilla.

So every new profile user who opens prefs for the first time to do anything like 
lets say clear cache will have these buttons disappear.

Now first off i think this is not 0.9.3 but is at least 0.9.2

Secondly I think this is a beta stopper because every new user who
has this happen in the beta will now have in there prefs.js files that reflect
having these buttons turned off.

So when the install RTM they will have no buttons either.  Now i know we don't 
get millions of beta users but there are a lot plus all the high profile people.  
We won't want those people not have the search button on RTM if they have tried 
the beta would we?

My vote would be to fix this for Beta rather then explain why
everyone who installs the beta with a new profile does not get
a search button or toolbar buttons for RTM.

Comment 15

[Lynn Webb]

I agree with Matt. The Search buttton on the toolbar and next to the location 
bar are affected by this bug.

Comment 16

[Lynn Webb]

If I scroll the list after opening Preferences, I see that Toolbar Search is 
unchecked. If I click OK, the Search button on toolbar (and sometimes also the 
one next to the URL bar) disappears. 

Comment 17

[Viswanath Ramachandran]

Matt - I think you're right in that we under-stated the importance of this bug.
 I'm moving it back to the m0.9.2 milestone since your comments describe the
severity of the problem. Also reassigning to you, please drive this. On beta,
lets try and get a patch ready before we see if we can hold that. 

Comment 18

[Viswanath Ramachandran]

-> matt

Comment 19

[matt]

I have mozilla patch...need to get one for commercial tree overlays.  Will post 
when done.  Moving checkboxes out of tree and into overlay.

Comment 20

[selmer (gone)]

We need to consider this for 091, the side-effect of losing these settings is
unrecoverable.  I'm not saying this is definitely a stopper, but we need to
determine the answer.

Comment 21

[selmer (gone)]

Matt, do you have a patch you can post yet?

Comment 22

[matt]

not yet.  On the commercial side i'm running into a small overlay problem that 
i'm addressing at the moment.

Comment 23

[selmer (gone)]

Not waiting -> 092.

Comment 24

[James Everingham]

I so wouldn't approve this bug, in fact I would spank matt silly.

Comment 25

[matt]

Attachment: patch to take checkboxes out of tree

Comment 26

[matt]

taking pref out of tree will correct this problem.

I still think this is the xbl binding problem that hyatt was thinking it 
originally was.  The only reason we are not seeing it sometimes is because prefs 
have a special mechanism with check boxes.
Filed bug http://bugzilla.mozilla.org/show_bug.cgi?id=84553 on it.

One last thing.  I would like to move the button item out of navigator and into 
appearence where there is more space.   Any objections and i'm asking if 
internationalization has a problem with this.

Comment 27

[Lynn Webb]

FYI. Please look at this bug for any internationalization problems.

Comment 28

[Jaime Rodriguez, Jr.]

Adding Bobj, Msanz, DanielMC, and FTang to cc: list?

Daniel/Michele/Ftang - Is this ok?

One last thing.  I would like to move the button item out of navigator and into 
appearence where there is more space.   Any objections and i'm asking if 
internationalization has a problem with this.

Comment 29

[danielmc]

No objection from Dublin. Although it makes more sense for the pref to be in 
Navigator as this is the only component the buttons are visible in.

Comment 30

[matt]

i agree with that but there might be a space crunch in navigator.
We going to test it on unix an mac before we do anything.  If space is not a 
concern then we won't move it.

Comment 31

[matt]

sleestack8 (1:47:11 PM): r=mcafee

Comment 32

[Blake Ross]

I don't think that label needs an id of "foo" :-)  Also, there's some wacky
indentation.  sr=blake, given the assurance that everything fits.

Comment 33

[matt]

fixed the foo and indents.

Need PDT baby

Comment 34

[Viswanath Ramachandran]

adding pdt+, this was nearly a m0.9.1 stopper. 

Comment 35

[matt]

Just to satify,  tested on mac & linux and everything fits.

Comment 36

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 37

[matt]

checked in

Comment 38

[Claudius Gayle]

VERIFIED Fixed on all platforms with 2001061415 builds