Closed
Bug 81149
Opened 24 years ago
Closed 24 years ago
Need to install preloader to startup folder on Windows
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: selmer, Assigned: slogan)
References
Details
Attachments
(2 files)
15.37 KB,
patch
|
Details | Diff | Splinter Review | |
15.37 KB,
patch
|
Details | Diff | Splinter Review |
(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.
Comment 1•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
I thought that was the point of the preloader?
Comment 5•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
I still think the best option would be to include it in the "component" dialog: [x] Navigator [x] Mail and News [x] FastLoader
Comment 8•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
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?
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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
Comment 15•24 years ago
|
||
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
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
Assignee | ||
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
sr=mscott
Comment 20•24 years ago
|
||
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Assignee | ||
Comment 21•24 years ago
|
||
Checked into the trunk prior to the 0.9.2 branch
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 22•24 years ago
|
||
The thing has been checked in. Still a lot of issues about this feature...
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•