Closed Bug 81149 Opened 24 years ago Closed 24 years ago

Need to install preloader to startup folder on Windows

Categories

(SeaMonkey :: Installer, defect)

x86
Windows 95
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: selmer, Assigned: slogan)

References

Details

Attachments

(2 files)

(if the preloader ships)

We need to install it into the windows startup folder.  Since there are several
alternatives being pursued, it would be good to get information into this bug
about how to install and invoke the various contenders.  Bill, Alec, Rick,
please add info here.
The best thing would be to show a dialog in the installer ala:

-------
Do you wish to install Mozilla FastLoader. This will enable faster startup time 
of Mozilla.
[x] Enable Mozilla FastLoader
-------

Perhaps this could just be moved to the "Component" setup dialog:
[x] Navigator
[x] Mail and News
[x] FastLoader

Anyway: There should be created a Mozilla FastLoader icon/application in the 
Windows startup folder so that people can easily remove the thing if they dont 
what it.
bad: 'enable faster startup time'
I thought that was the point of the preloader?
s/bad/bad wording/
A question mark is also needed. Text should say something like: "Do you wish to
install Mozilla FastLoader? This will enable Mozilla to start up faster." We
also should really warn users that this will require some memory.
I still think the best option would be to include it in the "component" dialog:
[x] Navigator
[x] Mail and News
[x] FastLoader
*** Bug 83879 has been marked as a duplicate of this bug. ***
Peter Lairo has filed bug 83882 about having UI within Mozilla to enable/disable
the preloader (kind of related to this bug).
using registry keys was suggested for -turbo, however we should not use:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
because it is *wrong* (the user probably does not have permission to modify 
HKLM), we should use:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Using reg keys is a good idea, it doesn't clutter up the startup folder (and
paranoid users (see bug 83879) will probably hava a clue on how to disable it).

I know nothing about this kind of programming, but I assume theres a way for the
installer to know if it's running in Win9x or NT/2000, and iff the latter if as
Administrator or a normal user. If Win9x or NT/administrator it should put the
key in HKEY_LOCAL_MACHINE so it loads the preloader for all users, if NT/normal
user put it in HKEY_CURRENT_USER so we don't get permission problems.
it's certainly possible to merely try to stick it into HKLM and if we get an 
Access Denied result try to stick it in HKCU, i'm just opposed to doing that.

The mozilla ui is for the user, nothing else in it controls the machine, so 
making this _one_ element affect the machine is *wrong*.

If you want the installer to try to stick it in HKEY_USERS\.default so that all 
new users get it I think that /might/ be ok.

Maybe i should spend time making the registry shell extension DnD friendly so I 
can drag the startup entry from one key to the other, but until someone does 
that, it's actually somewhat painful to move keys around the registry (mike 
lin's startup control panel is the only ui that makes it tolerable)
OS: other → Windows 95
Why is it so "wrong" to install the preloader for all users? I agree that if a
user installs it, it should only affect the one user. But if the installer is
run by Administrator, shouldn't it affect all users on the system?
ssu: do we have any specification for how the installer handles an 
administrative install vs a normal install? a grep of for 'dmin' and 'HKLM' 
didn't turn up anything interesting in xpinstall/

People run installers once and most settings can later be changed in prefs (bug 
?? for disabling preloader via prefs).  If we use the HKLM or the common 
startup folders then when someone tries to change it in prefs we'll (xpfe in 
trying to explain why they can't, the user in trying to figure out to do) have 
a problem -- and they won't be able to do anything about it.

If we use .default then each new user will get the setting and be able to 
change it as they wish.

notice Comments From Henrik Gemal 2001-05-16 00:09
Anyway: There should be created a ... FastLoader ... [somewhere] so people can 
*easily remove* the thing if they dont what it.

selecting HKLM or common startup (yes no one mentioned it, but there is such a 
thing, NT supports it) clearly defeats the flexibility that Henrik suggests.
There is no specification on how the installer should handle admin vs retricted 
user installs.

What it currently does (or would do) is this:  the win32 installer will always 
attempt to update HKLM.  If it determines that it has no access to HKLM, it will 
then try HKCU.

The reasoning behind this is that if the user has admin access, there's no 
reason why they would restrict themselves.  Even if they do, then can disable 
the preloader using their admin enabled account.

If they do not have access (their admin had installed the product for them),  
then they should ask their admin to disable the preloader for them.

If they do not have access and they installed mozilla themselves as a restricted 
user, then they have access to HKCU themselves and can disable the preloader.

I'm not even sure if Mozilla is supported in a retricted user account.
Status: NEW → ASSIGNED
Blocks: 75599
I mentioned the need for installer to add support for -turbo mode to Syd and 
Sean on Friday.  Syd will start take a crak at it.  

We still don't have a final decision and spec for rolling out -turbo mode 
feature, but right now we just want something quick in the installer to get 
turbo mode feature into people's hand for more broad testing...  
Assignee: ssu → syd
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla0.9.2
Attached patch patch that implements this (deleted) β€” β€” Splinter Review
Attached patch patch that implements this (deleted) β€” β€” Splinter Review
I've attached a file with my comments.  The 3rd item should definitely be done 
if we want to ship with the
turbo feature. 

Syd Logan wrote: 

  cathleen was hoping for this to land today, if you feel comfortable getting 
the review in tonight that'd be great
  but Monday is cool too.







some minor stuff:

** need to follow with the same coding format in browser.jst:
   don't use tabs, use spaces
   no space on either side of '(' or ')'.  example:
     'if ( index...' should be 'if(index...'
     '...\n" )' should be '...\n")'
   curly brace positions should also follow the convention of the rest of the 
.jst file.

** did you want to leave:
     /* logComment( "***********************install.arguments is " + 
Install.arguments ); */
   in browser.jst?

** We should have two new config.ini keys to control:

   [Dialog Start Install]
   ; Turbo Mode values: TRUE, FALSE
   ; Defaults to FALSE if not set.
   Turbo Mode=TRUE
   ; Turbo Mode Settings value: ENABLED, DISABLED
   ; Defaults to DISABLED if not set.
   ; This will hide the turbo mode checkbox in the Start Install
   ; dialog and ignore the Turbo Mode= key, thus disabling it.
   Turbo Mode Settings=ENABLED

   This would mean in addition to the bTurboMode var, we'll need to add a new 
one.  Perhaps call it:
     szTurboModeSettings

   If this is only for testing, then fixing the 1st two items will get you 
r=ssu.  However, if we're to ship with this, we should definitely add the above 
additional keys.  If we don't, one problem will be that eClient's CCK installer, 
which is based on the browser's installer code, will not be able to use disable 
the Turbo Mode checkbox, and thus will create the shortcut (something that is 
only used by the browser's installer).

Otherwise, it looks good.

r=ssu
sr=mscott
Blocks: 83989
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Checked into the trunk prior to the 0.9.2 branch 
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
The thing has been checked in. Still a lot of issues about this feature...
Status: RESOLVED → VERIFIED
Blocks: 90466
No longer blocks: 90466
No longer blocks: 75599
Blocks: 75599
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: