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

VERIFIED FIXED in mozilla0.9.2

Status

SeaMonkey
Preferences
P2
critical
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: Claudius Gayle, Assigned: matt)

Tracking

({regression})

Trunk
mozilla0.9.2
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pdt+]patch posted)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
***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?
(Reporter)

Comment 1

17 years ago
keywords
Keywords: nsbeta1, regression
cannot repro using 2001.05.16.12 bits. marking wfm! mebbe you got a Bad Set of
Builds...?
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

17 years ago
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.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Unchecking any toolbar button for the first time unchecks all other buttons → Unchecking any toolbar button for the first time unchecks buttons not in view
severity: its pretty bad if your chrome items like print button disappear
unintentionally. 
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.2
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. 
Priority: -- → P2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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.  
(Reporter)

Updated

17 years ago
Assignee: mcafee → vishy
Severity: major → critical
Status: REOPENED → NEW
Summary: Unchecking any toolbar button for the first time unchecks buttons not in view → Opening pref panel for the first time unchecks toolbar buttons not in view
Target Milestone: mozilla0.9.3 → ---
(Reporter)

Comment 7

17 years ago
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.

(Reporter)

Comment 8

17 years ago
remember this only happens the FIRST TIME.

Updated

17 years ago
Keywords: nsbeta1+ → nsbeta1

Comment 9

17 years ago
Vishy, I think we need to move this back into the stop ship pile - 0.9.2.
(Assignee)

Comment 10

17 years ago
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.
(Assignee)

Comment 11

17 years ago
.
Assignee: vishy → hyatt
(Assignee)

Comment 12

17 years ago
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.
Assignee: hyatt → vishy

Comment 13

17 years ago
nav triage team:

Marking nsbeta1+ and mozilla0.9.3
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 14

17 years ago
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

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

Comment 16

17 years ago
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. 
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. 
Target Milestone: mozilla0.9.3 → mozilla0.9.2
-> matt
Assignee: vishy → matt
(Assignee)

Comment 19

17 years ago
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

17 years ago
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.
Target Milestone: mozilla0.9.2 → mozilla0.9.1

Comment 21

17 years ago
Matt, do you have a patch you can post yet?

Updated

17 years ago
Whiteboard: [m0.9.1?]
(Assignee)

Comment 22

17 years ago
not yet.  On the commercial side i'm running into a small overlay problem that 
i'm addressing at the moment.
QA Contact: sairuh → claudius

Comment 23

17 years ago
Not waiting -> 092.
Whiteboard: [m0.9.1?] → [m0.9.1?] No.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 24

17 years ago
I so wouldn't approve this bug, in fact I would spank matt silly.
(Assignee)

Comment 25

17 years ago
Created attachment 37582 [details] [diff] [review]
patch to take checkboxes out of tree
(Assignee)

Comment 26

17 years ago
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.
Whiteboard: [m0.9.1?] No. → patch posted, need r sr and a

Comment 27

17 years ago
FYI. Please look at this bug for any internationalization problems.

Comment 28

17 years ago
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

17 years ago
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.
(Assignee)

Comment 30

17 years ago
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.
(Assignee)

Comment 31

17 years ago
sleestack8 (1:47:11 PM): r=mcafee
Whiteboard: patch posted, need r sr and a → patch posted, need sr and a

Comment 32

17 years ago
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.
(Assignee)

Comment 33

17 years ago
fixed the foo and indents.

Need PDT baby
Whiteboard: patch posted, need sr and a → patch posted, Need PDT baby
adding pdt+, this was nearly a m0.9.1 stopper. 
Whiteboard: patch posted, Need PDT baby → [pdt+]patch posted
(Assignee)

Comment 35

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

Comment 36

17 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
(Assignee)

Comment 37

17 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 38

17 years ago
VERIFIED Fixed on all platforms with 2001061415 builds
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.