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

Status: VERIFIED WONTFIX

(SeaMonkey :: Installer, defect, P2)

Description

[Todd Pringle]

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):

Bookmarks 
Home
My Netscape
Net2Phone
Toolbar Search
Shop
Print
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

[Mike Young]

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

[Todd Pringle]

nominating

Comment 3

[Paul Chen]

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
mozilla0.9.3

Comment 4

[Mike Young]

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

[Asa Dotzler [:asa]]

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

[Jason Kersey]

This is insane.

Comment 7

[Todd Pringle]

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

[Todd Pringle]

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

Comment 9

[Blake Ross]

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

[Todd Pringle]

Riskfree Fix is an oxymoron.  ;-)

Comment 11

[Blake Ross]

Weeeellll :-)

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

Comment 12

[Samir Gehani]

OK, so do we want this in mozilla or just commercial?  (Anyways, we need a bugscape bug for my commercial patch.)  

Comment 13

[Viswanath Ramachandran]

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

[Paul Chen]

nav triage team:

Marking nsBranch

Comment 15

[Viswanath Ramachandran]

Blake would you like to take this bug? 

Comment 16

[Viswanath Ramachandran]

--> vishy. Samir has left for sabbatical. This will need to go into the branch
only as it is not suitable for the mozilla trunk. 

Comment 17

[Viswanath Ramachandran]

-> vishy

Comment 18

[Viswanath Ramachandran]

--> morse. 

Comment 19

[Viswanath Ramachandran]

-> morse. 

Comment 20

[Viswanath Ramachandran]

as per PDT discussion today, we're not taking this for RTM. marking wontfix. 
sorry steve, thanks for working on the patch. 

Comment 21

[Stephen P. Morse]

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.

  <script>

    // Due to a bug in the pre-release, some of the showbuttons might have been 
lost.
    // To rectify this, the first time the 6.1 rtm is run, several of the 
showbuttons
    // 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['@mozilla.org/preferences;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("browser.toolbars.showbutton.search", true);
      pref.SetBoolPref("browser.toolbars.showbutton.reinitialized", true);

      // these four calls are not yet working
      showItem("netscapeshop-button");
      showItem("netscapesearch-button");
      showItem("mynetscape-button");
      showItem("net2phone-button");

      // these four calls work fine
      showItem("bookmarks-button");
      showItem("home-button");
      showItem("print-button");
      showItem("search-button");
    }

  </script>

Comment 22

[Grace Bush]

verified