***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?
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
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.
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 → ---
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.
remember this only happens the FIRST TIME.
Vishy, I think we need to move this back into the stop ship pile - 0.9.2.
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: vishy → hyatt
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
nav triage team: Marking nsbeta1+ and mozilla0.9.3
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.3
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.
I agree with Matt. The Search buttton on the toolbar and next to the location bar are affected by this bug.
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
Assignee: vishy → 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.
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
Matt, do you have a patch you can post yet?
not yet. On the commercial side i'm running into a small overlay problem that i'm addressing at the moment.
Not waiting -> 092.
Whiteboard: [m0.9.1?] → [m0.9.1?] No.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I so wouldn't approve this bug, in fact I would spank matt silly.
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
FYI. Please look at this bug for any internationalization problems.
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.
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.
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.
sleestack8 (1:47:11 PM): r=mcafee
Whiteboard: patch posted, need r sr and a → patch posted, need sr and a
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.
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
Just to satify, tested on mac & linux and everything fits.
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
VERIFIED Fixed on all platforms with 2001061415 builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.