Closed Bug 325561 Opened 17 years ago Closed 17 years ago

1.5.0 -> 1.5.0.1 partial update fails if search plugin to be patched is missing

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: vectorspace, Assigned: preed)

Details

(Keywords: fixed1.8.0.2, Whiteboard: [rft-dl])

Attachments

(1 file)

Ignore removed search plugins
875 bytes, patch
darin.moz
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8) Gecko/20051111 Firefox/1.5

If a file to be patched by the auto-update is missing, the update fails. This seems like a good thing, but its not. 

Firstly, it did not tell me that the update failed. I expected it to alert me that it failed and offer to download the full installer update.
I clicked help > check for updates and saw that 1.5.0.1 was listed. I clicked Install, it downloaded, and then told me it needed to restart. I let it - it restarted. I saw the 'installing update' progress bar window, but the progress bar never moved and the window vanished very quickly. Then Firefox 1.5 started, not updated. There was no error or wanrning saying that the update failed or anything like that.
Help > About still listed the 1.5 UA
Options > Advanced > Update > Show Update History it was listed as 'install pending' or something like that.
I tried restarting Firefox to see if the install would continue, it wouldn't.
I clicked help > check for updates and 1.5.0.1 was still listed. I tried letting it install again, and the same thing happened.

Secondly, the missing file was a search plugin. Correct me if I'm wrong, but aren't these are supposed to be removeable?
I checked last-update.log and saw it failed right after trying to patch the ebay plugin - right after this:
PREPARE PATCH searchplugins/eBay-en-GB.src
I opened the 1.5 en-GB installer with 7-Zip and extracted the search plugins, and copied them into Firefox's plugins folder. Then I tried updating again, and this time it worked.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox 1.5
2. Delete the search plugins
3. Start Firefox, click help > check for updates and download & install the 1.5.0.1 update.
Actual Results:  
See that it has not updated

Expected Results:  
Update should be applied.

The problem has been discussed in thes mozillaZine forum thread: http://forums.mozillazine.org/viewtopic.php?t=375453
OS: Other → Windows 2000
Hardware: Other → PC
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming on win32 - removing the Amazon searchplugin from 1.5 en-US gives this snippet from last-update.log:

PREPARE PATCH updater.ini
PREPARE PATCH plugins/npnul32.dll
PREPARE PATCH searchplugins/amazondotcom.src
failed: 6
calling QuitProgressUI

Leaving aside the notification issues (due to the automatic download settings - please file another bug for that if it doesn't exist already), this bug can be solved a couple of ways:
1) Make the commands PATCH-IF instead of PATCH
2) Copy search plugins to the profile on creation (and probably plugin update) so that the user can customize their profile without affecting the global defaults.
I like solution one, but I'm not fond of solution two; While running, Firefox displays the search plugins in the application folder as well as the profile folder. For solution two to work, then Firefox would also have to stop displaying the installation folder search plugins

As to Firefox not notifying me when my update failed, I'll try to reproduce it before I think about filing a bug for it.
(In reply to comment #2)
> For solution two to work, then Firefox would also have to stop
> displaying the installation folder search plugins

The default search plugins should simply go into the default profile settings. i.e. move firefox/searchplugins to firefox/defaults/profile/searchplugins/

While it's a good idea to continue support for global search plugins, there's no real reason why they need to be there by default.

Making this change would solve two problems:

1) Partial updates failing because the file was deleted.
2) Manual updates re-creating deleted plugins.

My concerns with this approach are:

1) What happens when Firefox attempts to load duplicate plugins? This is what may happen when:
   i. An existing installation has firefox/searchplugins.
   ii. It gets updated.
   iii. A new profile is created.

2) This obviously won't help until the release *after* this bug is fixed, but then neither will Nick's first approach I'd guess.

3) Someone, somewhere might rely on firefox/searchplugins specifically. This shouldn't actually take affect unless they're performing a clean install, though, and manual creation is still an option. Just like extensions, these really belong in the profile.

Other thoughts:

1) AUS isn't really necessary for search plugins, they have their own checkbox in the Options UI.

2) Implementing Nick's first option is probably a good idea, but his second one should also be done. Having global search plugins by default doesn't make a lot of sense.

My opinion of the bug/situation:

This should be branch-viable and low risk if all that is required is a directory relocation. Is there any chance we can stop this madness if and when there's a 1.5.0.2?

Nominating due to AUS-bustage with a couple of plausible fixes and no obvious reason (at least, to me) to leave it broken.
Flags: blocking1.8.0.2?
This is weird. I ran into this issue with Firefox on OS X...but I hadn't deleted any search plugins (in fact, I just recently found out how to get inside an application folder...yes I am new to OS X).

Don't know why my partial update failed...
Chris, do you mean that your <firefox install dir>/updates/last-update.log indicates the update failed on a searchplugin, or just that the partial failed ? Note that the full update has probably overwritten the partial update log.
UPDATE FAILED

last-update.log

PREPARE PATCH browserconfig.properties
PREPARE PATCH xpicleanup.exe
PREPARE ADD softokn3.chk
PREPARE PATCH js3250.dll
PREPARE PATCH nspr4.dll
PREPARE PATCH softokn3.dll
PREPARE PATCH plds4.dll
PREPARE PATCH firefox.exe
PREPARE PATCH ssl3.dll
PREPARE PATCH LICENSE
PREPARE PATCH xpcom.dll
PREPARE PATCH xpcom_core.dll
PREPARE PATCH plc4.dll
PREPARE PATCH AccessibleMarshal.dll
PREPARE PATCH nssckbi.dll
PREPARE PATCH xpistub.dll
PREPARE PATCH xpcom_compat.dll
PREPARE ADD removed-files
PREPARE PATCH nss3.dll
PREPARE PATCH updater.exe
PREPARE PATCH smime3.dll
PREPARE PATCH updater.ini
PREPARE PATCH plugins/npnul32.dll
PREPARE PATCH searchplugins/amazondotcom.src
PREPARE PATCH searchplugins/creativecommons.src
PREPARE PATCH searchplugins/eBay.src
PREPARE PATCH searchplugins/answers.src
PREPARE PATCH searchplugins/yahoo.src
PREPARE PATCH searchplugins/google.src
PREPARE PATCH greprefs/xpinstall.js
PREPARE PATCH greprefs/all.js
LoadSourceFile failed
failed: 8
calling QuitProgressUI
hotbot, that is a different error. Please file a new bug if it is reproducable.

A general note: a bug report does not work like forum thread. They
1) should be focused on a single issue 
2) should not become a dumping ground for problems with a particular feature and/or release

(In reply to comment #7)
> hotbot, that is a different error. Please file a new bug if it is reproducable.

you are right. i have no clue (why my update failed)
it's not my job to figure that out.

if you know why my update failed you should file that bug.

The simple solution for this bug is to make the searchplugins optional just like the extensions folder.  In other words, change "patch" to "patch-if".

See tools/update-packaging/common.sh
(In reply to comment #5)
> Chris, do you mean that your <firefox install dir>/updates/last-update.log
> indicates the update failed on a searchplugin, or just that the partial failed
> ? Note that the full update has probably overwritten the partial update log.
> 

I have no idea, because the full update afterwards overwrote the partial update attempt (which btw, is very stupid...the log should keep at least the last two attempts in there). The only thing I have changed in Firefox is adding some extensions, but that is stored in the profile and the firefox update shouldn't have touched them (outside of disabling non-compatible ones).

I'm just stating that I hadn't deleted any search plugins...so this bug might have additional causes.
(In reply to comment #9)
> The simple solution for this bug is to make the searchplugins optional just
> like the extensions folder.  In other words, change "patch" to "patch-if".

Shall I file a new bug for getting them moved to a sane location, then?
The partial update from 1.5 to 1.5.0.1 failed on three of my four systems.  It failed on a Windows 2000 SP4 and two Windows XP SP2.

     Software Update
     Update Failed
     The partial Update could not be applied.
     Firefox will try again by downloading a
     complete Update.

The complete update then succeeded.  The partial update only succeeded on a Windows Server 2003 SP1.

The Windows installs are English versions with Icelandic regional settings.  Firefox is English version.

I have a number of extensions installed on the systems that failed and I have also deleted some of the default search plugins.  I have no extensions installed on the system that succeeded and have left the search plugins intact.

There have been some speculations that a partial update will fail if some of the default search plugins are missing.  If that's the case then surely it must be fixed.  There is no need to increase the download ten-fold just so that I can delete the default search plugins yet again?
(In reply to comment #12)
> There have been some speculations that a partial update will fail if some of
> the default search plugins are missing.

There's no speculation - it's been confirmed. The partial update patches many files, including search plugins. If any file to be patched is missing the partial update will quit.

The correct fix here is to provide a way to disable individual search plugins that does not invovle the user needing to remove files that are part of the default installation.
(In reply to comment #14)
> The correct fix here is to provide a way to disable individual search plugins
> that does not invovle the user needing to remove files that are part of the
> default installation.

Why is that necessary? What's wrong with the solution from comment 9?
(In reply to comment #15)
> (In reply to comment #14)
> > The correct fix here is to provide a way to disable individual search plugins
> > that does not invovle the user needing to remove files that are part of the
> > default installation.
> 
> Why is that necessary? What's wrong with the solution from comment 9?
> 

Well that is sufficient to fix this issue of making the auto update work if the user is smart enough to figure out how to find and remove the appropriate file to diable a particualr search plugin.

My point is just hat the users should not have to do that in the first place, and if there was a method to allow the users to configure the search plug-ins (like there should be) this problem would correct itself.

(In reply to comment #16)
> My point is just hat the users should not have to do that in the first place,
> and if there was a method to allow the users to configure the search plug-ins
> (like there should be) this problem would correct itself.

Ok, but that isn't this bug :). For what it's worth, that will be fixed in Firefox 2. See bug 317107.
We definitely need some sort of fix for the partial updates here. Even if we replace all the search plugins that's better than failing.
Assignee: nobody → preed
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Is this problem in Firefox, or the install script in the partial update?

Is it part of the partial update format to patch a file only if it exists? If thats the case, then there is no bug to be fixed in Firefox itself - just some changes to the instructions that are followed in the creation of a partial update.
(In reply to comment #19)
> Is it part of the partial update format to patch a file only if it exists? If
> thats the case, then there is no bug to be fixed in Firefox itself - just some
> changes to the instructions that are followed in the creation of a partial
> update.

Yes, see comment 9.
Thanks - I didn't know if that was fact or a suggestion. I didn't notice the source reference.
I agree that it is very important for this bug to be corrected.  One of the things that is putting some people off with Firefox is the lack of a simple updating process.  I did want to mention that I had two seperate installs of Firefox (Different Computers, both Win XP SP2).  I removed one Search Plugin from one of the computers, and as everyone knows the update failed.  I reset the update file, and replaced the search plugin.  I was offered the small update file again, and downloaded it.  The update still failed.  I ran the full update and that worked.  On the other computer I never removed any search plugins and the update still failed.  The only thing I can think is that I rearranged the order of the search plugins under about:config.  I was instructed in doing so on the forums, as there isn't a simple way of doing this within the Firefox browser, which i don't quite understand.  I hope the ability to rearrange the Search Plugins, etc. is planned for Firefox 2.0.  At least that's the only reason I can think of for the one update failing.  

Thanks,
-Matt-

        Attachment #214249 -
        Flags: review?(darin)

    
    

    
  
Comment on attachment 214249 [details] [diff] [review]
Ignore removed search plugins

r=darin

        Attachment #214249 -
        Flags: review?(darin) → review+

    
    

    
  
adding keyword for preed
Keywords: fixed1.8.0.2

    
    

    
  
Fix checked in Mar 6
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [rft-dl]

    
    

    
  
Is this script change needed on the 1.8 branch as well?
Flags: blocking-firefox2?

    
    

    
  
I believe that release engineering is just using the tools from the trunk.  It's also possible that these scripts are not even branched for FF2, so I don't think we need to take this for FF2.
Flags: blocking-firefox2? → blocking-firefox2-

    
    

    
  
(In reply to comment #27)
> Is this script change needed on the 1.8 branch as well?
> 

I don't think its needed in FF2, given FF2's changes to the search plugin system.

In FF2, the search plugins are still in the application folder, but are no longer used straight from there - they are copied to the profile folder and used from there. There's no longer any need to delete the search plugins from the application folder and so no need for them to be deletable.

Unless someone wants to be able to change their default search plugin set for all new profiles.

    
    

    
  
(In reply to comment #29)
> In FF2, the search plugins are still in the application folder, but are no
> longer used straight from there - they are copied to the profile folder and
> used from there.

That statement is incorrect. The search plugins are still read directly from the application directory, and are not copied to the profile folder. When they are "removed" using the UI, an attribute is set in the profile causing them to not be displayed.

That means that it's now less likely that people will delete search plugins manually, therefore people are less likely to hit this bug. However, as Darin mentioned already, this only changed the packaging scripts, so Firefox 2's new search system isn't really relevant to the question at hand (whether this patch should be landed on the branch) :)
Product: Firefox → Toolkit

          You need to log in
          before you can comment on or make changes to this bug.