351260 - No provision for disabling welcome and override pages

Status: RESOLVED FIXED

(Firefox :: Settings UI, enhancement)

Description

[Harry Johnston]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5
Build Identifier: 

The 2.0 branch doesn't allow the administrator to prevent the welcome and
override pages from being shown (the 1.5 branch did, though it may have been an
unintentional feature).  Disabling these pages is desirable when using Firefox
on a intranet without direct internet access.

Reproducible: Always

Comment 1

[Harry Johnston]

Attachment: patch to allow admin to disable override and welcome pages

I've attached a patch that would allow this.  To make use of this feature, the
administrator would add one or both of the following lines to
defaults/pref/all.js:

pref("startup.homepage_override_url", "ignore");
pref("startup.homepage_welcome_url", "ignore");

(Apologies if the patch isn't formatted correctly; I have yet to learn CVS.)

Comment 2

[Reed Loden [:reed]]

Comment on attachment 236666 [details] [diff] [review]
patch to allow admin to disable override and welcome pages

Thanks for volunteering, gavin.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 236666 [details] [diff] [review]
patch to allow admin to disable override and welcome pages

This isn't the right fix, more in a sec.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Harry:
Assuming the method you mention in comment 0 is "set browser.startup.homepage_override.mstone to 'ignore' in firefox.js", I don't see this issue with current branch, because the patch for bug 324093 didn't land there. I do see this issue on the trunk.

Could you clarify which build you're testing, and what you're doing that worked in 1.5 but doesn't with a current 2.0 branch build?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Please renominate if it becomes clear that this is a branch-related issue.

Comment 6

[Harry Johnston]

(In reply to comment #4)

With the 1.5.0.5 release you can say

pref("startup.homepage_override_url", "ignore");

in all.js and this will disable the override page, this is probably unintentional (but useful) behaviour.  (When the preference is retrieved an exception is raised because the value isn't a valid localized string, the exception skips the code that returns the override page.)

> Assuming the method you mention in comment 0 is "set
> browser.startup.homepage_override.mstone to 'ignore' in firefox.js"

As an admin I don't like to mess with firefox.js, if only because each new release of Firefox will overwrite my change, but I guess you could do this in all.js just as well.  

However, I don't think it would work either way if there was an existing user profile, because the setting in the profile would have priority.  (I'm away from my testbed at the moment so can't doublecheck that right now.)

Conceptually speaking it seems to me that mstone is a user property, "the last version I was using" so setting it to ignore is meaningful when a particular user wants to say "don't track my versions".  On the other hand, homepage_override_url is a system setting, "the page to display if this is a new version" so it would be a more meaningful setting to change if the administrator wants to say "don't display any page for new versions".

Comment 7

[Harry Johnston]

OK, I've filed Bug 352063 regarding the regression error on the trunk.

While setting the default value of browser.startup.homepage_override.mstone to ignore doesn't work for new profiles, using lockPref to lock the value to ignore does.  So I have an alternative solution for this feature request.

I'm going to request another review of the patch I proposed, because I do think that conceptually it is a cleaner solution, but if Gavin disagrees with me we can close this bug.

Comment 8

[Harry Johnston]

To clarify my previous comment, using lockPref to set the default value of browser.startup.homepage_override.mstone to ignore works in the 1.5.0.x branch and in the 2.0 branch but not on the trunk.  The fact that this doesn't work on the trunk is the regression error I filed as Bug 352063.

Comment 9

[Harry Johnston]

Attachment: better version

I've changed the special case URL from the arbitrary string "ignore" to about:blank because the latter makes more sense.  This also makes it consistent with the corresponding code later in the same procedure:

    if (startpage == "about:blank")
      startpage = "";

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 238133 [details] [diff] [review]
better version

Sorry I took so long on this one, Harry. I'll check this in for you some time this week.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/components/nsBrowserContentHandler.js 	1.31