122540 - need command-line option to reset home page, search prefs

Status: VERIFIED FIXED

(Core Graveyard :: Cmd-line Features, enhancement)

Description

[Curt Patrick (gone)]

The installer team needs this option.  It must cause the browser to silently
revert  to the homepage to the default homepage.  The installer will take care
of getting permissions from the user to do the revert, and then launch the newly
installed/upgraded browser using this command-line option.

Comment 1

[Curt Patrick (gone)]

Darn it.  I meant to enter this in bugscape, not bugzilla.  Please ignore.

Comment 2

[Curt Patrick (gone)]

On the other hand, looks like there isn't anyplace outside of mozilla for this
to do.  I recon this must be implemented in mozilla and the installer
implementation that uses it will be only in bugscape.  Sorry for the confusion
on my end.

Comment 3

[Peter Trudelle]

If so, it should probably be generalized to -reverthome <URL>
We also need to know which profile to revert.

Comment 4

[timeless]

-P profilename
can't you do this already with -P profilename 
javascript:_lots_of_voodoo_to_set_homepage?

my guess is that javascript: would run as chrome and therefor have permission 
to make the change.

alternatively please check to see whethere ie has a similar commandline option

Comment 5

[Jesse Ruderman]

Timeless: javascript: URLs passed to mozilla through the command line do not 
and should not have chrome permissions, because other applications can't be 
expected to check for javascript: and data: URLs before passing a URL to 
Mozilla.

Comment 6

[Daniel Veditz [:dveditz]]

no <url> parameter, the desire was to stomp any user pref and therefore pick up
the built-in defaults. Mktg also wants the same for the search engine so a
better syntax might be -revert <list> where list is either a set of pre-defined
keywords (home, search) or maybe arbitrary raw pref names. And maybe
"-resetpref" instead of the more ambiguous -revert

I'd rather this be done by signed JS in the "What's New" first-start page, if
that hadn' been taken over by a giant Movie ad. This mechanism would only catch
the profile launched after doing the install, the "What's New" page gives us a
crack at each profile after the upgrade, and again if the user ever uses the
"What's New" help menu item. The options to be changed can then be completely
decoupled from the MachV schedule -- it would magically start working for
current 6.2.1 downloads, for instance.

Comment 7

[Peter Trudelle]

Doing this via the What's New page is far preferable from a user standpoint too,
since on shared machines since the person making the decision at install time
would not necessarily be the one being affected in each profile.

Comment 8

[Gregg Landskov (gone)]

Doing it in the What's New Page isn't the best option for us right now for a
couple reasons.

1.  We don't own the page...we are working on this aspect of it and *probably*
will have partial control of it prior to Mach V, but as of today we don't.
2.  If we did own the page, while it is true that we could track it independent
of the Mach V schedule, to implement on the page it will need to go thru CPD
anyway which wouldn't save any engr time.  In my opinion, trying to secure a web
engineering resource or production resource in Columbus to do this correctly
would take more time than either CPD option.
3.  I thought dveditz had mentioned that the command line implementation would
only affect the current profile the user is installing to, not all the profiles
on a particular machine.  Dan?
4.  While we run some risk of upsetting some users with this feature, it is too
important to the business to not put it in.  Putting it in an installer panel 
maximizes the effectiveness of bringing people to Netscape.com.  It will be in a
prominent spot (not buried) in the installer wizard.  Users have to expect that
with any free software that there are going to be hooks, and as long as we are
not trying to sneak it by them, we think it is appropriate and worth any
negative risk.

Comment 9

[timeless]

well a commandline option won't work for multiple profiles. and abusing the profile registry will fail miserably on certain platforms (esp unix derivatives, ideally NT derivatives, ...).  So you're really stuck with first run behaviors.

afaik there's nothing wrong with having the firstrun start page be chrome which redirects to a remote site later.  you can reset homepages and stuff from the chrome context. [jesse can specify how to prevent the chrome context from being passed to the webpage, although i'd expect that it would just work]

Comment 10

[Peter Trudelle]

Gregg, I wasn't suggesting we not put it in, but rather that we offer to reset
all the profiles in the right way.  Is there any way to have the first page on
first run after install be per profile, and load a local file URL?  We could
even use XUL...

Comment 11

[Daniel Veditz [:dveditz]]

The first start page comes up per-profile. Maybe we could make a chrome page
that's *really* "What's New" with static content from docs, framing the web site
page so the site guys get their ad in. The left side could be a TOC that will
load chrome pages into the frame overwriting the ad, and part of the chrome code
could be hooks that ask if you want to revert your homepage etc if it detects
it's not the default.

That's assuming "What's New" content and menu item are valuable to us, otherwise
we should get rid of that menu item. Could still do the framing trick where the
chrome is an invisible border but could still run code.

Comment 12

[Bill Law]

I'll target this as soon as I can tell what exactly it is that needs to be 
implemented.

Comment 13

[Gregg Landskov (gone)]

Sorry for taking so long to comment...

At this point, we don't have the "What's New" page and we can't assume that we
will have it come release.

We need to proceed forward with the command line (-resetpref, or whatever engr
wants) and installer wizard panel UI option.  

This is really important to the business...I realize it might not be the most
elegant or ideal implementation, but we need to get it in as soon as possible.

Bill - can you do the work on the Browser end?  If so, when is a reasonable
target date?

Thanks

Comment 14

[Peter Trudelle]

Marking nsbeta1+

Comment 15

[Daniel Veditz [:dveditz]]

Rewording the summary to be less specific, we may not want literally
"-reverthome" since we'll have at least two options (home, search).

Option 1:
 -reverthome -revertsearch
Option 2:
 -resetpref home,search
Option 3:
 -resetpref browser.startup.homepage,browser.search.defaultengine
others?

The third option would be the most flexible looking to the future (core code
wouldn't have to change to add a new option); the ugliness would be hidden in
the installer. Otherwise between options 1 and 2 it's up to you whether it's
easier to handle two independent options or a list.

Comment 16

[Bill Law]

Dan, I really like option 3.  Than I can use it for useful things, too :-).

Did anybody ever answer the question about which profile(s) are affected?

I'd like to require "-P profilename" (or cause the Profile Manager to appear) as
that is the way things work now.

Also, it would only work if Mozilla is not already running.

Please speak up if there are problems with any of those restrictions.  I'm going
to proceed with implementation; I hope to have it done for mozilla0.9.9 (should
be able to, barring controversy).

Comment 17

[Curt Patrick (gone)]

We already make sure that mozilla gets shut down before completing the install,
so that concern is covered.

Gregg, seems like the "-P profilename" requirement is another UI consideration
that needs to go into your spec.  What about multiple profiles?

Comment 18

[Bill Law]

Curt and I talked about this this afternoon.

After some discussion, the installer would like to accomplish the pref 
resetting at the same time it launches the initial browser window.  It uses 
the "-install" flag when it does that so we decided that that flag could be 
followed by an arbitrary string of prefs to be reset, separated by commas.

The trick is that we have to wait to process those prefs till after the user 
starts a profile (which may be never, I suppose, if they exit the profile 
manager).  So I'm going to find the code that handles "-install" currently and 
see if it can be tweaked to do the additional work of parsing out the prefs and 
resetting them.

Comment 19

[Bill Law]

Attachment: New component to handle -resetPref cmdline arg

I've gone back to a new -resetPref cmdline argument.

We can implement that with a stand-alone component without requiring any
changes to any other code.  I've attached a component that implements this.  I
plan to add this under xpfe/components/resetPref (with appropriate win/unix/mac
build system changes).	One can test this for now by just placing this
component in your bin/components directory.

Probably the Mozilla distribution won't have to ship this component.  Netscape
can add it to their distribution (by modifying the packaging lists).

The code is pretty simple.  Curt, can you review that, please?	I'll post
another patch with build system changes on Monday.

Comment 20

[Bill Law]

Attachment: New component in patch form

This is missing only the Mac build script magic.

Comment 21

[Curt Patrick (gone)]

Bill, your moving quicker than I can keep up now!  I'm trying a new build with
your patch.  In the meantime I looked over your code, although I hardly qualify
to review js code that implements interfaces as I've never done anything like
that.  None-the-less, I saw nothing that looked egregious.

On the other hand, I tried to just use the new component and have not been
successful.  Here is what I did; perhaps you see an error in my process:

1) I saved your js file as components\nsResPrefs.js
2) From the folder where regxpcom lives I executed "regexpcom.exe" and got no
errors.
3) I executed "netscp6.exe" to confirm that I have a homepage other than
home.netscape.com.
4) I did a File|Exit to close all my browser instances.
5) I executed "netscp6.exe -resetPref browser.startup.homepage".  My expectation
was that my homepage would revert to home.netscape.com but it remained the same.

Any idea where I went wrong?

Comment 22

[Bill Law]

Attachment: Update (fixed a typo in nsResetPref.js)

Comment 23

[Curt Patrick (gone)]

Comment on attachment 70203 [details] [diff] [review]
Update (fixed a typo in nsResetPref.js)

My review is more functional than a code review.  I applied the patch, built
with it, confirmed that nsResetPref.js landed in the components directory, and
confirmed that the command line worked for resetting the home.	I did look over
the code but someone more qualified--Dan or maybe Alec--needs to scrutinize it.

BTW, don't we need a patch for ns to float some of the make file changes in
that get the js file into the components directory?

Comment 24

[Daniel Veditz [:dveditz]]

Comment on attachment 70203 [details] [diff] [review]
Update (fixed a typo in nsResetPref.js)

>Index: allmakefiles.sh
>===================================================================
>RCS file: /cvsroot/mozilla/allmakefiles.sh,v
>retrieving revision 1.342
>diff -u -5 -r1.342 allmakefiles.sh
>--- allmakefiles.sh	14 Feb 2002 01:33:17 -0000	1.342
>+++ allmakefiles.sh	19 Feb 2002 01:48:08 -0000
>@@ -674,10 +674,11 @@
> xpfe/components/urlbarhistory/public/Makefile
> xpfe/components/urlbarhistory/src/Makefile
> xpfe/components/urlwidget/Makefile
> xpfe/components/winhooks/Makefile
> xpfe/components/console/Makefile
>+xpfe/components/resetPref/Makefile
> xpfe/components/build/Makefile
> xpfe/appshell/Makefile
> xpfe/appshell/src/Makefile
> xpfe/appshell/public/Makefile
> xpfe/bootstrap/Makefile
>Index: xpfe/components/Makefile.in
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/Makefile.in,v
>retrieving revision 1.30
>diff -u -5 -r1.30 Makefile.in
>--- xpfe/components/Makefile.in	9 Feb 2002 03:15:55 -0000	1.30
>+++ xpfe/components/Makefile.in	19 Feb 2002 01:48:08 -0000
>@@ -24,11 +24,11 @@
> srcdir		= @srcdir@
> VPATH		= @srcdir@
> 
> include $(DEPTH)/config/autoconf.mk
> 
>-DIRS		= bookmarks directory filepicker find history search sidebar related regviewer xfer prefwindow shistory timebomb console autocomplete urlbarhistory intl
>+DIRS		= bookmarks directory filepicker find history search sidebar related regviewer xfer prefwindow shistory timebomb console autocomplete urlbarhistory intl resetPref
> 
> ifdef MOZ_ENABLE_XREMOTE
> DIRS		+= xremote
> endif
> 
>Index: xpfe/components/makefile.win
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/makefile.win,v
>retrieving revision 1.31
>diff -u -5 -r1.31 makefile.win
>--- xpfe/components/makefile.win	9 Feb 2002 05:35:15 -0000	1.31
>+++ xpfe/components/makefile.win	19 Feb 2002 01:48:08 -0000
>@@ -39,9 +39,10 @@
>     autocomplete \
>     urlbarhistory \
>     winhooks \
>     urlwidget \
>     intl \
>+    resetPref \
>     build \
>     $(NULL)
> 
> include <$(DEPTH)\config\rules.mak>
>Index: xpfe/components/resetPref/MANIFEST
>===================================================================
>RCS file: xpfe/components/resetPref/MANIFEST
>diff -N xpfe/components/resetPref/MANIFEST
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ xpfe/components/resetPref/MANIFEST	19 Feb 2002 01:48:08 -0000
>@@ -0,0 +1 @@
>+nsResetPref
>Index: xpfe/components/resetPref/Makefile.in
>===================================================================
>RCS file: xpfe/components/resetPref/Makefile.in
>diff -N xpfe/components/resetPref/Makefile.in
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ xpfe/components/resetPref/Makefile.in	19 Feb 2002 01:48:08 -0000
>@@ -0,0 +1,34 @@
>+# 
>+# The contents of this file are subject to the Mozilla Public
>+# License Version 1.1 (the "License"); you may not use this file
>+# except in compliance with the License. You may obtain a copy of
>+# the License at http://www.mozilla.org/MPL/
>+# 
>+# Software distributed under the License is distributed on an "AS
>+# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
>+# implied. See the License for the specific language governing
>+# rights and limitations under the License.
>+# 
>+# The Original Code is mozilla.org code.
>+# 
>+# The Initial Developer of the Original Code is Netscape
>+# Communications, Inc.  Portions created by Netscape are
>+# Copyright (C) 2001, Mozilla.  All Rights Reserved.
>+# 
>+# Contributor(s):
>+
>+DEPTH		= ../../..
>+topsrcdir	= @top_srcdir@
>+srcdir		= @srcdir@
>+VPATH		= @srcdir@
>+
>+include $(DEPTH)/config/autoconf.mk
>+
>+JSCOMPONENTS = \
>+	nsResetPref.js \
>+	$(NULL)
>+
>+include $(topsrcdir)/config/rules.mk
>+
>+libs:: $(JSCOMPONENTS)
>+	$(INSTALL) $^ $(DIST)/bin/components
>Index: xpfe/components/resetPref/makefile.win
>===================================================================
>RCS file: xpfe/components/resetPref/makefile.win
>diff -N xpfe/components/resetPref/makefile.win
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ xpfe/components/resetPref/makefile.win	19 Feb 2002 01:48:08 -0000
>@@ -0,0 +1,30 @@
>+#!nmake
>+# 
>+# The contents of this file are subject to the Mozilla Public
>+# License Version 1.1 (the "License"); you may not use this file
>+# except in compliance with the License. You may obtain a copy of
>+# the License at http://www.mozilla.org/MPL/
>+# 
>+# Software distributed under the License is distributed on an "AS
>+# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
>+# implied. See the License for the specific language governing
>+# rights and limitations under the License.
>+# 
>+# The Original Code is mozilla.org code.
>+# 
>+# The Initial Developer of the Original Code is Netscape
>+# Communications, Inc.  Portions created by Netscape are
>+# Copyright (C) 2001, Mozilla.  All Rights Reserved.
>+# 
>+# Contributor(s):
>+
>+DEPTH=..\..\..
>+
>+JSCOMPONENTS = \
>+    .\nsResetPref.js \
>+    $(NULL)
>+
>+include <$(DEPTH)\config\rules.mak>
>+
>+libs:: $(JSCOMPONENTS)
>+        !@$(MAKE_INSTALL) $(JSCOMPONENTS) $(DIST)\bin\components
>Index: xpfe/components/resetPref/nsResetPref.js
>===================================================================
>RCS file: xpfe/components/resetPref/nsResetPref.js
>diff -N xpfe/components/resetPref/nsResetPref.js
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ xpfe/components/resetPref/nsResetPref.js	19 Feb 2002 01:48:08 -0000
>@@ -0,0 +1,162 @@
>+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
>+ *
>+ * The contents of this file are subject to the Netscape Public License
>+ * Version 1.1 (the "License"); you may not use this file except in
>+ * compliance with the License.  You may obtain a copy of the License at
>+ * http://www.mozilla.org/NPL/
>+ *
>+ * Software distributed under the License is distributed on an "AS IS" basis,
>+ * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
>+ * for the specific language governing rights and limitations under the
>+ * License.
>+ *
>+ * The Original Code is the Mozilla browser.
>+ *
>+ * The Initial Developer of the Original Code is Netscape Communications 
>+ * Corporation.  Portions created by Netscape are 
>+ * Copyright (C) 2001 Netscape Communications Corporation.  All Rights
>+ * Reserved.
>+ *
>+ * Contributors:
>+ *  Bill Law    <[e-mail]>
>+ */
>+
>+/* This file implements the nsICmdLineHandler interface.  See nsICmdLineHandler.idl
>+ * at http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/public/nsICmdLineHandler.idl.
>+ *
>+ * This component handles the startup command line argument of the form:
>+ *   -resetPref pref1,pref2,pref3
>+ * by resetting the user prefs pref1, pref2, and pref3 (an arbitrary list of pref names
>+ * separated by commas).
>+ *
>+ * The module is registered under the contractid
>+ *   "@mozilla.org/commandlinehandler/general-startup;1?type=resetPref"
>+ *
>+ * The implementation consists of a JavaScript "class" named nsResetPref,
>+ * comprised of:
>+ *   - a JS constructor function
>+ *   - a prototype providing all the interface methods and implementation stuff
>+ *
>+ * In addition, this file implements an nsIModule object that registers the
>+ * nsResetPref component.
>+ */
>+
>+/* ctor
>+ */
>+function nsResetPref() {
>+}
>+
>+nsResetPref.prototype = {
>+    // Turn this on to get debugging messages.
>+    debug: false,
>+
>+    // nsICmdLineHandler interface
>+    get commandLineArgument() { throw Components.results.NS_ERROR_NOT_IMPLEMENTED; },
>+    get prefNameForStartup()  { throw Components.results.NS_ERROR_NOT_IMPLEMENTED; },
>+    get chromeUrlForTask()    { 
>+        try {
>+            // We trust that this has been called during command-line handling during
>+            // startup from nsAppRunner.cpp.
>+
>+            // We get the command line service and from that the -resetPref argument.
>+            var cmdLine  = Components.classes[ "@mozilla.org/appshell/commandLineService;1" ]
>+                             .getService( Components.interfaces.nsICmdLineService );
>+            var prefList = cmdLine.getCmdLineValue( "-resetPref" ).split( "," );
>+
>+            // Get pref service.
>+            var prefs    = Components.classes[ "@mozilla.org/preferences-service;1" ]
>+                             .getService( Components.interfaces.nsIPrefService );
>+
>+            // For each pref specified on the cmd line, reset the user pref value.
>+            for ( i in prefList ) {
>+                var pref = prefs.getBranch( prefList[ i ] );
>+                try {
>+                    pref.clearUserPref( "" );
>+                } catch( e ) {
>+                }
>+            }
>+        } catch( e ) {
>+            this.dump( "exception: " + e );
>+        }
>+
>+        // Return an error (so nsAppRunner doesn't think we've opened a window).
>+        throw Components.results.NS_ERROR_NOT_IMPLEMENTED;
>+    },
>+    get helpText()            { throw Components.results.NS_ERROR_NOT_IMPLEMENTED; },
>+    get handlesArgs()         { throw Components.results.NS_ERROR_NOT_IMPLEMENTED; }, 
>+    get defaultArgs()         { throw Components.results.NS_ERROR_NOT_IMPLEMENTED; }, 
>+    get openWindowWithArgs()  { throw Components.results.NS_ERROR_NOT_IMPLEMENTED; }, 
>+
>+    // nsISupports interface
>+
>+    // This "class" supports nsICmdLineHandler and nsISupports.
>+    QueryInterface: function (iid) {
>+        if (!iid.equals(Components.interfaces.nsICmdLineHandler) &&
>+            !iid.equals(Components.interfaces.nsISupports)) {
>+            throw Components.results.NS_ERROR_NO_INTERFACE;
>+        }
>+        return this;
>+    },
>+
>+    // Dump text (if debug is on).
>+    dump: function( text ) {
>+        if ( this.debug ) {
>+            dump( "nsResetPref: " + text + "\n" );
>+        }
>+    },
>+
>+    // This Component's module implementation.  All the code below is used to get this
>+    // component registered and accessible via XPCOM.
>+    module: {
>+        // registerSelf: Register this component.
>+        registerSelf: function (compMgr, fileSpec, location, type) {
>+            compMgr = compMgr.QueryInterface( Components.interfaces.nsIComponentManagerObsolete );
>+            compMgr.registerComponentWithType( this.cid,
>+                                               "Pref Reset Component",
>+                                               this.contractId,
>+                                               fileSpec,
>+                                               location,
>+                                               true,
>+                                               true,
>+                                               type );
>+        },
>+    
>+        // getClassObject: Return this component's factory object.
>+        getClassObject: function (compMgr, cid, iid) {
>+            if (!cid.equals(this.cid))
>+                throw Components.results.NS_ERROR_NO_INTERFACE;
>+    
>+            if (!iid.equals(Components.interfaces.nsIFactory))
>+                throw Components.results.NS_ERROR_NOT_IMPLEMENTED;
>+    
>+            return this.factory;
>+        },
>+    
>+        /* CID for this class */
>+        cid: Components.ID("{15ABFAF7-AD4F-4450-899B-0373EE9FAD95}"),
>+    
>+        /* Contract ID for this class */
>+        contractId: "@mozilla.org/commandlinehandler/general-startup;1?type=resetPref",
>+    
>+        /* factory object */
>+        factory: {
>+            // createInstance: Return a new nsResetPref object.
>+            createInstance: function (outer, iid) {
>+                if (outer != null)
>+                    throw Components.results.NS_ERROR_NO_AGGREGATION;
>+    
>+                return (new nsResetPref()).QueryInterface(iid);
>+            }
>+        },
>+    
>+        // canUnload: n/a (returns true)
>+        canUnload: function(compMgr) {
>+            return true;
>+        }
>+    }
>+}
>+
>+// NSGetModule: Return the nsIModule object.
>+function NSGetModule(compMgr, fileSpec) {
>+    return nsResetPref.prototype.module;
>+}

Comment 25

[Daniel Veditz [:dveditz]]

Arg! sorry about that... busted build, or busted attachment page submits itself
on the first edit.

Comment 26

[Daniel Veditz [:dveditz]]

>+++ xpfe/components/resetPref/MANIFEST	19 Feb 2002 01:48:08 -0000
>@@ -0,0 +1 @@
>+nsResetPref

Should that be "nsResetPref.js" ?

>+# The contents of this file are subject to the Mozilla Public
>+# License Version 1.1 (the "License"); you may not use this file

New files should get the "tri-license" header. See http://www.mozilla.org/MPL/
for boilerplate.

>+# Copyright (C) 2001, Mozilla.  All Rights Reserved.

2002, and it can't be "Mozilla" if you  already claimed it was Netscape on the
line above. In any case "Mozilla" is a browser, and AFAICT "mozilla.org" is a
virtual organization that can't really hold copyrights.

You need clean:: and clobber_all:: targets in the unix and win makefiles
respectively

>+++ xpfe/components/resetPref/nsResetPref.js	19 Feb 2002 01:48:08 -0000
>@@ -0,0 +1,162 @@
>+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
>+ *
>+ * The contents of this file are subject to the Netscape Public License

We've been asked not to use the NPL for new files. Use the MPL "tri-license".
Again the copyright date would be 2002

gotta run, will look more later

Comment 27

[Bill Law]

Attachment: Updated licenses, fixed MANIFEST, added clobber rules

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 70451 [details] [diff] [review]
Updated licenses, fixed MANIFEST, added clobber rules

r=dveditz

Comment 29

[Joe Hewitt (gone)]

Comment on attachment 70451 [details] [diff] [review]
Updated licenses, fixed MANIFEST, added clobber rules

sr=hewitt

Comment 30

[Bill Law]

Attachment: Trivial patch to Mac build script to process MANIFEST file

This is the line that needs to be added to the Mac build script to process the
new MANIFEST file (and copy the component implementation .js to the components
directory).

Comment 31

[Asa Dotzler [:asa]]

Comment on attachment 70451 [details] [diff] [review]
Updated licenses, fixed MANIFEST, added clobber rules

a=asa (on behalf of drivers) for checkin to the _trunk_

Comment 32

[Bill Law]

Resetting target milestone since this is OKd for the trunk.

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 71784 [details] [diff] [review]
Trivial patch to Mac build script to process MANIFEST file

sr=dveditz

Comment 34

[Bill Law]

feature is now in place

Comment 35

[Curt Patrick (gone)]

I'm testing this with the commandline "mozilla -install -resetPref
browser.startup.homepage".  nsResetPref.js is not being installed with todays
build (which is no surprise since I didn't see any changes to the installer as
part of the patches...and I'd have been the one to make them anyway).  So, it
looks to me like the installer needs to be modified to install nsResetPref.js
and to run regxpcom before we can actually say that this feature is in place. 
I'm reopening the bug and assigning it to myself.

Bill, is there anything else the installer needs to do that I'm overlooking?

Sean, do I need to do anything special to get the installer to launch regxpcom
or  does that happen already anyway?  I'm suspecting that it does, but I took a
quick look through the code and didn't immediately see any place where this was
obviously happening.


 

Comment 36

[Curt Patrick (gone)]

Oh yeah.  I said I was going to assign it to myself also.  Here goes.

Comment 37

[Bill Law]

Curt, I'm not sure what you mean by "the installer needs to be modified to
install nsResetPref.js and to run regxpcom before we can actually say that this
feature is in place."

Is that the same as adding nsResetPref.js to the xpinstall/packager/ package
lists?  That's all that needs to be done, I think.  And if the installer feature
that uses this is in the Netscape-only distribution, then that should happen
only in the Netscape distribution.

Comment 38

[Curt Patrick (gone)]

Attachment: moz patch for packages files

Yeah, I overstated the problem.  Something about the regxpcom thing wigged me
out.  As penance I've created this patch.

Bill, I believe that we do want to go ahead and install this for mozilla as
well as ns.  The mozilla installer won't be using the functionality right now
(it will be turned off via a config.ini setting) but if it ever does it will be
available.  Also, some other installer based on Mozilla may decide to turn it
on and be justifiably confused if the functionality doesn't kick in.

Comment 39

[Sean Su]

Comment on attachment 73154 [details] [diff] [review]
moz patch for packages files

r=ssu

Comment 40

[Daniel Veditz [:dveditz]]

I disagree, changing a user's preference on them is not very nice and I don't 
see the need to make Mozilla vulnerable to this if we don't have a specific 
plan to use it. The code is there if some other distributor wants to add it.

Comment 41

[Curt Patrick (gone)]

Attachment: 0.1 for mozilla

All the functionality to recapture the homepage is in this patch, but it is all
turned off in the config.it settings.  Although the settings would be turned
off by default anyway, I have explicitely turned them off with comments about
what their pupose is.

NS patch to follow will turn install the required component and turn on the
functionality.

Comment 42

[Curt Patrick (gone)]

Comment on attachment 73760 [details] [diff] [review]
0.1 for mozilla

Attachment is for another bug,not this one.

Comment 43

[Curt Patrick (gone)]

Bill and Dan are right.  We will not install the component for Mozilla, so I'm
closing this bug.  I'll add the installation step to the patch for ns specific
implementation.

Comment 44

[sairuh (rarely reading bugmail)]

i cannot seem to get this to work at all --at least on linux. my homepage isn't
being reset. using the following cmds didn't revert my homepage using
2002.03.12.08 commercial bits:

./netscape -resetPref browser.startup.homepage
./netscape -P test-1 -resetPref browser.startup.homepage
./netscape -P test-1 -resetPref 'browser.startup.homepage'
./netscape -installer -resetPref browser.startup.homepage

i also tried the following on win2k, to no avail:

netscp6 -resetPref browser.startup.homepage
netscp6 -resetPref -installer browser.startup.homepage

am i using an incorrect format? fwiw, on both platforms i have multiple profiles...

Comment 45

[Curt Patrick (gone)]

BTW, I see that sarah is trying to qa this, which is kind of hard to do since it
is not being installed, and won't be on mozilla.  Since this functionality is
exclusively for installer support, and since I have tested that it does what we
need in installer land I propose that we push the real testing off onto bug
#122684 and its companion ns installer bug.

Comment 46

[sairuh (rarely reading bugmail)]

many thanks to Curt for the clarification. gonna rs vrfy this one...