Confirmed users
1,247
edits
Talk:Support/Firefox Features/Clean install: Difference between revisions
Jump to navigation
Jump to search
Talk:Support/Firefox Features/Clean install (view source)
Revision as of 01:37, 28 April 2011
, 28 April 2011→The installer is not a good option
| Line 4: | Line 4: | ||
Further clarification: | Further clarification: | ||
* We already lock down almost everything in the installation directory so there should be very few files that can be added that would affect the application. I may be mistaken but I believe the only problem area is the plugins directory at this time. | * We already lock down almost everything in the installation directory so there should be very few files that can be added that would affect the application. I may be mistaken but I believe the only problem area is the plugins directory at this time. | ||
** False. We also had a major problem a few versions ago where half-installed files from old installations caused Firefox to not start. I agree this isn't the elegant option, it's the nuclear option, but it lets users recover from anything rather than having to have us account for all the possible problems. | |||
* I have had conversations with people that have stated that deleting the installation directory fixes problems but they haven't taken the time to identify the file(s) that caused the problem. If there are things we should be locking down that we aren't then we should definitely identify them and lock them down. | * I have had conversations with people that have stated that deleting the installation directory fixes problems but they haven't taken the time to identify the file(s) that caused the problem. If there are things we should be locking down that we aren't then we should definitely identify them and lock them down. | ||
** Why? I'll admit that we've been trying to fix the problem rather than ID the file causing the problem but again, it seems rather than keeping a blacklist of third party files or whatever else, we just complicate the problem. | |||
* Locking down the installation directory prevents the user from experiencing problems whereas what is outlined in this feature is a method to solve problems AFTER the user is already experiencing problems. Out of those two options, making it so the user doesn't experience problems should be a MUCH higher priority as I see it. | * Locking down the installation directory prevents the user from experiencing problems whereas what is outlined in this feature is a method to solve problems AFTER the user is already experiencing problems. Out of those two options, making it so the user doesn't experience problems should be a MUCH higher priority as I see it. | ||
** I agree that locking down the installation directory is a good thing to do. That said, if we're doing that anyway, what's the harm in deleting files that aren't being used anyway. | |||
* The current feature outline leverages the Windows installer which will only work on Windows whereas by locking down the installation directory further than it already is will provide benefit to all platforms. | * The current feature outline leverages the Windows installer which will only work on Windows whereas by locking down the installation directory further than it already is will provide benefit to all platforms. | ||
** On Mac, this already happens. When you drag a newly downloaded Firefox into the Applications folder, it replaces the existing one. On linux, I think the same is true, if you untar our folder into another one, it replaces everything. | |||
* In the future we will have both a Windows NSIS installer and a Windows MSI installer so implementing this in the installer will require two separate implementations. | * In the future we will have both a Windows NSIS installer and a Windows MSI installer so implementing this in the installer will require two separate implementations. | ||
** Ok. | |||