Closed Bug 263595 Opened 20 years ago Closed 19 years ago

Installer option to reset homepage should be false by default.

Categories

(Firefox :: Installer, defect)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: moz.n1, Assigned: bugs)

References

(
URL
)

Details

Attachments

(1 file)

Screenshot
68.61 KB, image/png
Details 
The fix for bug 262953 causes firefox installer to prompt "Use firefox start as
my homepage". Upgraders would typically not want to lose their homepage, so this
should default to false.

Also, due to bug 225281, the finish screen looks awkward.
Attached image Screenshot — 
Adding screenshot
Flags: blocking-aviary1.0?
Is this a dataloss issue? (Maybe that keyword should be added)

Just fast clicking through the installer might let you lose your (maybe
important)homepage. 
Maybe default false for nightlies and default true for releases. Or, if the
installer can detect the existence of a profile, only default true if no profile
exists.
Surely if no profile exists then a newly created profile will have the firefox
start page set by default anyway. Basically meaning that this option only really
does anything if a profile already does exist.
If no profile exists, the import wizard will import the home page along with the
rest of the imported settings. I assume the check box would override the
imported home page.
It used to be that Mozilla sent new users the FIRST time they started to the URL
in startup.homepage_override_url -- after that, it would go to their old home
page. I don't know if FireFox does this anymore.

The first time I installed FireFox on my computer, I was surprised to see the
msn website as the home page. I had just installed Windows, so when FireFox
imported settings, it imported the default home page along with it. 

FireFox is moving towards the u.m.o upgrade process, where people will not have
to run the installer to get new versions. Once this happens, the only people
running the installer will be those installing FireFox on that computer for the
first time. That means that they should be sent at least once to the FireFox
start page. 
I suggest that it should be on by default when migrating from another browser,
and off by default when upgrading an existing installation of Firefox.

Also, if there is no other browser to migrate settings 'from' (such as on an OS
where a web browser is not pre-installed) then this setting has no effect and
should not appear.
Does this mean that the installer should not really have this option and rather
the code that does importing from other browsers should just be changed to not
import the home page?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
The option should be off by default unless the user doesn't have a home page
already.  Just because the user has migrated to firefox from another browser
doesn't mean that they want to lose their homepage.  I believe that the firefox
start page should however be displayed the first time the user launches a newly
installed version of firefox, possibly with a section explaining why they are
seeing this page instead of their normal home page, and telling them that they
won't see it again.
(In reply to comment #6)
> It used to be that Mozilla sent new users the FIRST time they started to the URL
> in startup.homepage_override_url -- after that, it would go to their old home
> page. I don't know if FireFox does this anymore.

That is how I remember it as well, and the best solution. That way you get the
best of both worlds. It introduces the user to that page and then the next time
they start up, it goes "home".
As far as I'm concerned the selector in the installer should default to 'off' as
people are quite capable of choosing their homepage for themselves. Having
downloaded Firefox, they will in all likelihood have visited the Firefox website
and having migrated from another browser, they may be annoyed to find that their
homepage has been changed be default. The option should remain in the installer
so that people can choose to set their homepage to it but because updates will
be displayed to the user in the update feature of the browser, the average end
user may not wish to visit the Firefox page and should not be forced to by default.
*** Bug 284662 has been marked as a duplicate of this bug. ***
*** Bug 287426 has been marked as a duplicate of this bug. ***
This is an even bigger problem given that FF keeps releasing point security
fixes (1.0.1 and 1.0.2) - though these are delivered via u.m.o, they're still
full-fledged installers. For these versions, the majority of the people
installing them will be upgraders, and therefore already have a profile complete
with a homepage. For these people, you will be causing problems, forcing them to
set their homepage if they ignored the checkbox on the last dialog of the installer.

The two options are: 
* turn the checkbox on and risk the user losing their homepage (some users may
not know how to set it back). 
* turn the checkbox off and risk the user missing out on a start page which has
google search on it. given that google search is available as part of sherlock,
I'd say this is a much smaller risk.

Besides, the correct way to introduce this would be after profile migration. "We
just copied your settings from IE, would you like to use your old homepage (MSN)
or switch to our google co-branded one?"
(In reply to comment #14)
>
> This is an even bigger problem given that FF keeps releasing point security
> fixes (1.0.1 and 1.0.2) - though these are delivered via u.m.o, they're still
> full-fledged installers.

This is in an interesting point, something I noticed surprised "newly-former" IE
users when 1.0.1 was released.  It should be possible to only update the binary
files that are involved and not use a complete install for an update, for many
reasons:  

Such an update would minimise the update download, which is important for many
users on slow connections or that pay based on data transferred.  On Windows
there might be a slight problem since out of the approx. 15-16MB install then
firefox.exe is 6.3MB.  It is not broken into sufficiently small parts so that
any update will always be 7MB+.

It would not change any settings.  Modifying settings during a patch update is
known as "slamming" and should only be done when there are absolutely no other
options to fix a critical bug.

The update could be completely automatic, and not start a complete install
process requiring clicking multiple Next buttons and answering questions, like
the current process does, which is way too complicated for many home users.





*** Bug 288010 has been marked as a duplicate of this bug. ***
I'm probably missing something, but this looks like a one line change to 
seamonkey/source/toolkit/mozapps/installer/windows/wizard/setup/extra.c

I'm not set up to do builds, so if someone wants to verify that fact and make a
real patch that can be checked in, go for it.

***************
*** 2,8 ****
HRESULT InitDlgInstallSuccessful(diIS *diDialog)
  {
    diDialog->bShowDialog = FALSE;
    diDialog->bLaunchAppChecked = TRUE;
!   diDialog->bResetHomepageChecked = TRUE;
    if((diDialog->szTitle = NS_GlobalAlloc(MAX_BUF)) == NULL)
      return(1);
    if((diDialog->szMessage0 = NS_GlobalAlloc(MAX_BUF)) == NULL)
--- 2,8 ----
HRESULT InitDlgInstallSuccessful(diIS *diDialog)
  {
    diDialog->bShowDialog = FALSE;
    diDialog->bLaunchAppChecked = TRUE;
!   diDialog->bResetHomepageChecked = FALSE;
    if((diDialog->szTitle = NS_GlobalAlloc(MAX_BUF)) == NULL)
      return(1);
    if((diDialog->szMessage0 = NS_GlobalAlloc(MAX_BUF)) == NULL)
*** Bug 287485 has been marked as a duplicate of this bug. ***
*** Bug 285712 has been marked as a duplicate of this bug. ***
Hopefully we won't be using the full installer for updates in the future (1.1
and beyond). This should probably just be a branch concern where we've hacked up
update to deliver a full installer rather than the nifty XPIs.
Flags: blocking-aviary1.0.3+
the boolean value should be initialized to FALSE if the installer has been
invoked from the update process, vs. downloading from the website where it
should be TRUE. 
(In reply to comment #20)
> Hopefully we won't be using the full installer for updates in the future (1.1
> and beyond). This should probably just be a branch concern where we've hacked up
> update to deliver a full installer rather than the nifty XPIs.

Except for those of us who regularly install nightlies from the installer like I
do about every other day. It gets very annoying having to unclick that checkbox.
(In reply to comment #21)
> the boolean value should be initialized to FALSE if the installer has been
> invoked from the update process, vs. downloading from the website where it
> should be TRUE. 

But if the user downloaded from the website, ran the installer and imported 
settings from another browser?  Shouldn't it be FALSE then to not lose the 
imported home page?  Or is it set to FALSE regardless after an import happens?
(In reply to comment #21)

> the boolean value should be initialized to FALSE if the installer has been
> invoked from the update process, vs. downloading from the website where it
> should be TRUE. 

What about corporate networks, networks behind firewalls or content blockers,
individuals that buy the CD from the Mozilla Foundation (or elsewhere), or
anyone else who has who knows what other reasons for downloading and installing?

I'll bet there are a fair number of people that don't even realize that the
installer works like it does.  Or maybe they don't have the bandwidth at home,
so they burn it to CD at work.
(In reply to comment #17)
> I'm probably missing something, but this looks like a one line change to 
> seamonkey/source/toolkit/mozapps/installer/windows/wizard/setup/extra.c
> 
> I'm not set up to do builds, so if someone wants to verify that fact and make
> a real patch that can be checked in, go for it.

No, that didn’t work. However there is a second instance of the
bResetHomepageChecked variable, and setting that one to FALSE *did* work.

However, I think the reason for not unchecking this box by default might be that
Google is generating funds for the foundation, and this is thus not an
acceptable solution (as this will also keep the option unchecked for new users).
Just speculation, of course :).


~Grauw
I've just done a little experiment to see what effect this option actually has.
I think I've covered all the basic cases (though didnt test with users other
than the user who installed). I was quite surprised by the results:

1st case, a Firefox profile already exists.
  If set homepage is checked, starting firefox shows the google start page.
  If set homepage is not checked, starting firefox shows the original home page.

2nd case, no Firefox profile exists, user opts to import from IE.
  If set homepage is checked, starting firefox shows the google start page.
  If set homepage is not checked, starting firefox shows the google start page.

3rd case, no Firefox profile exists, user opts not to import.
  If set homepage is checked, starting firefox shows the google start page.
  If set homepage is not checked, starting firefox shows the google start page.

What does this say? It says that the only users that this option has an effect
on are the users who have used firefox before and are mearly upgrading. And
right now the option defaults to the setting that causes those users inconvenience.

Let me expand on what Dave said in comment 26.

There are four common installation scenarios:
1) No existing FF profile, don't import
2) No existing FF profile, import settings from IE
3) No existing FF profile, import settings from another browser
4) Existing FF profile, use it

And the current behavior in those scenarios:
1) The checkbox has no effect
2) The checkbox has no effect (bug 252546)
3) The checkbox resets the imported homepage
4) The checkbox resets the existing user specified homepage

The proposed solution is to default the checkbox to unchecked in all cases. The
only two scenarios that would be affected by such a change are scenarios 3 and 4.

For scenario 3, I would argue that most users would probably prefer to use the
imported home page.

For scenario 4, the current behavior is undesired, which is the reason this bug
was filed. Ben agreed in comment 21.

In either case, defaulting the checkbox to unchecked only removes the
possibility that users will mistakenly reset existing homepages. New users and
those migrating from IE won't be affected at all.
Version: unspecified → Trunk
*** Bug 291158 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
This didn't make aviary1.0.3, so transferring blocking-aviary1.0.3+ to
blocking-aviary1.0.4+.
Flags: blocking-aviary1.0.4+
We need to get this sorted out for all cases on the trunk. That's what this bug
should cover. For the branch, we're going to be be hacking the windows update
package to not have this checked by default.
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.4+
Flags: blocking-aviary1.0.3+
*** Bug 293851 has been marked as a duplicate of this bug. ***
This bug also appears not only on Trunk builds, but also on aviary builds,
including the just released Firefox 1.0.4. I suggest that its "Version" be
changed to "Unspecified" since it's impossible to set it to "All".
(In reply to comment #30) (In reply to comment #31) (In reply to comment #32)
> We need to get this sorted out for all cases on the trunk. That's what this bug
> should cover. For the branch, we're going to be be hacking the windows update
> package to not have this checked by default. 

Is there a known equivalent aviary-branch bug? If there isn't, I'm ready to
reopen my bug 293851 and mark it as Aviary-branch, "blocking-1.0.5?" (1.0.4 is
out, it can't be blocked anymore).
>I think the reason for not unchecking this box by default might be that
> Google is generating funds for the foundation, and this is thus not an
> acceptable solution (as this will also keep the option unchecked for new 
users).

I really hope that no decision is based on this sort of commercial motive 
(although I realise it was probably partly tongue-in-cheek). It sort of defeats 
the purpose of Open Software don't you think... ?
(In reply to comment #25)
[...]
> However, I think the reason for not unchecking this box by default might be that
> Google is generating funds for the foundation, and this is thus not an
> acceptable solution (as this will also keep the option unchecked for new users).
> Just speculation, of course :).
> 
> 
> ~Grauw

Subsidies or no, the default should IMHO be to keep the user-set homepage, if
there is one. I suggest the following action:

1) No previous Fx install and no import. Checkbox setting doesn't matter, a new
profile is created anyway with its homepage pointing to Google. I suggest
greying the option.
2) Install over an existing Fx profile. I suggest the checkbox default to off.
3) No previous Fx install and settings are imported from some other browser (IE,
Netscape, Mozilla, whatever). I suggest the following:
3a) If the imported homepage points to one of a small list of "browser makers'"
sites (microsoft.com, netscape.net, mozilla.org, etc.) open an additional
installer page (or modify the existing one) to say something like:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Your homepage is currently set to <URL> which looks like the default homepage
for your previous browser. Which home page would you like to use with Firefox?
(*) Firefox Start
( ) Imported page from my old browser settings

You will have more options later, using Firefox's Tools -> Options menu.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

3b) Otherwise, import the homepage setting (presumably already user-set) and
leave the default off in [ ] Make Firefox Start your home page


Best regards,
Tony.
(In reply to comment #35)

From your suggestion you seem to be advocating getting rid of this checkbox
altogether, none of your scenarios use it. I thoroughly support that :)

(In reply to comment #36)
> (In reply to comment #35)
> 
> From your suggestion you seem to be advocating getting rid of this checkbox
> altogether, none of your scenarios use it. I thoroughly support that :)
> 

Yes and no.

- If there already exists an obviously "user set" homepage (including all cases
with an existing profile), I see no harm in letting the user replace it by
Firefox Start provided that the default action (if the user does nothing) be to
leave the homepage unchanged. In that case though, I wouldn't fight against
checkbox removal either.
- If there is no existing profile and no import, the checkbox has no effect anyway.
- If the imported user page seems to be a default one, I believe that the
default action should be to set Firefox Start as homepage, but in such way as to
make the user immediately conscious of the change, with a possibility of
overriding it now in favour of the imported homepage and the knowledge that he
will have more options later (e.g., it is not useful to have the option to set a
blank homepage or a multitab homepage-set in the installer but it is useful to
keep those options in the Options dialog). Note that my.netscape.com is a
"user-set" page even though it resides in the same domain as home.netscape.com
which is a "default" page.
I am still wondering why upgrading to a nightly via the installer actually has
no option of leaving everything set by the former version.
I.e. on windows the desktop, quicklaunch and menu option as well as the
start-page, of course.
Some users tend to keep their desktop clean and sort the start-menu in
sub-folders and it is exteremely annoying if one upgrades and finds the icons
flooding the desktop again.

Having this high frequency of updates an option in the Setup Type could handle
the  problem:
Standard - Custom - Upgrade
The last option keeps everything like it was before, if there is no significant
change in the different versions (where it has to ask anyway)
*** Bug 294483 has been marked as a duplicate of this bug. ***
*** Bug 294790 has been marked as a duplicate of this bug. ***
Given the changes introduced in bug 294399 this bug is now fixed on the trunk as
the option no longer exists. So the blocking 1.1 flag can be removed. 

See bug 294399#26

Could the option removal changes in bug 294399 be back ported to the branch
incase there are anymore branch security updates? Or should this bug now be closed?

Comment 30 says this should cover the trunk cases -> close bug as fixed?
We're not taking anything except security fixes on the branch at this point, so
no backporting.  Fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I've been cut off from the Net for slightly more than two weeks, and on return I
notice that the bug has also been fixed on the aviary-1.0.1 branch. I guess it
happened when Firefox 1.0.5 was released. Good. I'm un-voting for this bug while
leaving myself in the CC list. If anyone is against marking this bug VERIFIED
(because he's still seeing it in a "current" build -- I'm not), I guess "now or
never" is the time to speak up.
*** Bug 300484 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: