Need to set prefs for toolbar buttons to true for rtm release



18 years ago
7 years ago


(Reporter: tpringle, Assigned: morse)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: has to go on branch only.)



18 years ago
Bug 81093 described how users will lose various toolbar buttons when opening the
Nav pref panel in certain situations.  As we did not fix this in beta, some
users will encounter this situation and likely not fix the problem by going back
into prefs and re-adding the buttons.

As several of these lost buttons are key revenue drivers, it is important that
we turn them back on by default in the final release.  Recommend that we set the
following prefs to true by default to force them back on (but still allow users
to go in and uncheck to remove):

My Netscape
Toolbar Search

I realize of course that these are largely commercial items, but as the behavior
affects standard Mozilla buttons as well, filing in Bugzilla.

Comment 1

18 years ago
Actually, this is probably good for Mozilla as well. For the 1.0 release, the
browser should set many of the prefs (the cosmetic ones) back to the default (or
on) settings. This way people can see all of the features available to use. As
mozilla has been deemed a "developer" application and not a "client" per se, I
think its not asking too much for people to uncheck the prefs in the dialog the
first time they use 1.0 (It is a *complete* new browser -- even if people are
upgrading from the nightly before) :-)

However, This type of action should ONLY be done for 1.0 (and perhaps for new
features for 2.0 and such) regular releases should respect the users settings

Comment 2

18 years ago
Keywords: nsbeta1

Comment 3

18 years ago
nav triage team:

This is the followup to fixing the loosing personal toolbar items. Because
they're now turned off, need to re-enable them. Marking nsbeta1+, p2, and
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3

Comment 4

18 years ago
ummmm isn't nsbeta1 already out? shouldn't this be nsbeta2+ ???

Maybe I'm just not up an the netscape numbering scheme... I mean, it was 
suppossed to be 6.5 :-)

Comment 5

18 years ago
Absolutely not! If netscape wants this then they will have to take it on the
branch.  I cannot believe anyone would even suggest this. People customize their
apps.  If an upgrade deletes my prefs that is a bug. We've been fixing bugs like
this for several years now and I cannot believe someone is suggesting
intentionally introding a new one.

Comment 6

18 years ago
This is insane.

Comment 7

18 years ago
Asa, what we're trying to do here is fix a pref dataloss bug in 0.9.1 by
restoring the default settings.  A fair number of users will lose buttons in the
main toolbar and personal toolbar during 0.9.1.  Some will make changes
themselves also, as you note.  If Mozilla doesn't want to solve this problem for
the ones who hit the bug, I have no problem with that - Mozilla users are
probably savvy enough to go in and add back buttons that they lose when they hit
this bug anyway.

Comment 8

18 years ago
BTW, I'm glad to refile in Bugscape as well - just let me know.

Comment 9

18 years ago
We had a riskfree fix for bug 81093 and Matt clearly explained the ramifications 
of not getting the fix into beta, but it was pushed out.  It's troublesome that 
users once again have to suffer because of our mistakes.

Comment 10

18 years ago
Riskfree Fix is an oxymoron.  ;-)

Comment 11

18 years ago
Weeeellll :-)

Compared to the other ones taken for beta1, it was close enough. It just changed 
the UI a tiny bit.

Comment 12

18 years ago
OK, so do we want this in mozilla or just commercial?  (Anyways, we need a bugscape bug for my commercial patch.)  
I think it is okay to take this on the Netscape RTM branch (after m0.9.2 is out
the door, and Netscape owns the branch) in the mozilla tree. This shd not be in
the mozilla trunk. 

Comment 14

18 years ago
nav triage team:

Marking nsBranch
Keywords: nsBranch


18 years ago
QA Contact: gemal → gbush
Blake would you like to take this bug? 
--> vishy. Samir has left for sabbatical. This will need to go into the branch
only as it is not suitable for the mozilla trunk. 
Whiteboard: eta 7/6. has to go on branch only.
-> vishy
Assignee: sgehani → vishy
--> morse. 
-> morse. 
Assignee: vishy → morse


18 years ago
Whiteboard: eta 7/6. has to go on branch only. → has to go on branch only.
as per PDT discussion today, we're not taking this for RTM. marking wontfix. 
sorry steve, thanks for working on the patch. 
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 21

18 years ago
FWIW, I'm including the beginnings of a patch that I had developed before this 
bug got marked wont-fix.  Just in case this ever gets resurected, it's good to 
save the work that was done.

The following code goes into navExtraOverlay.xul.  It works fine as far as 
resetting the prefs.  However it doesn't cause all the buttons to be redisplayed 
immediately.  In fact, it redisplays four out of the eight.  I think all eight 
get redisplayed on the next browser launch, but I haven't done enough testing to 
determine this.  Problem was that not all the buttons were created at the time 
this code was called, so the document.getElementById was failing on those.  
Ironically, three of the ones it was failing on are the ones that are defined in 
the navExtraOverlay.xul file itself -- namely netscapeshop, netscapesearch, and 
mynetscape.  The fourth one it failed on was net2phone.


    // Due to a bug in the pre-release, some of the showbuttons might have been 
    // To rectify this, the first time the 6.1 rtm is run, several of the 
    // will get turned back on.  See bugzilla bug 85220 for details.

    function showItem(id) {
      var item = null;
      item = document.getElementById(id);
      if (item) {
        var hidden = item.getAttribute("hidden");
        item.setAttribute("hidden", false);
        var styleIn = item.getAttribute("style");
        var styleOut = styleIn;
        // Remove style="display:none;".
        styleOut = styleOut.replace("display:none;", "");
        // Only set style if it's different.
        if (styleIn != styleOut) {
          item.setAttribute("style", styleOut);

    var pref;
    pref = Components.classes[';1'];
    pref = pref.getService();
    pref = pref.QueryInterface(Components.interfaces.nsIPref);
    try {
      if (pref.GetBoolPref("browser.toolbars.showbutton.reinitialized")) {
        // showbuttons were previously reinitialized, nothing more to do
    } catch(e) {
      // pref doesn't exist meaning that showbuttons were never reinitialized
      pref.SetBoolPref("browser.toolbars.showbutton.bookmarks", true);
      pref.SetBoolPref("browser.toolbars.showbutton.home", true);
      pref.SetBoolPref("browser.toolbars.showbutton.mynetscape", true);
      pref.SetBoolPref("browser.toolbars.showbutton.net2phone", true);
      pref.SetBoolPref("browser.toolbars.showbutton.netscapesearch", true);
      pref.SetBoolPref("browser.toolbars.showbutton.netscapeshop", true);
      pref.SetBoolPref("browser.toolbars.showbutton.print", true);
      pref.SetBoolPref("", true);
      pref.SetBoolPref("browser.toolbars.showbutton.reinitialized", true);

      // these four calls are not yet working

      // these four calls work fine


Comment 22

18 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.