470193 - "engine has no file" error when trying to manage engines after removing engine from the appdir manually

Status: RESOLVED DUPLICATE of bug 427028

(Firefox :: Search, defect)

Description

[mirko2324]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1b3pre) Gecko/20081217 Shiretoko/3.1b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1b3pre) Gecko/20081217 Shiretoko/3.1b3pre

If I delete or add a search engine xml file in the program oder profile folder the list is not updated.

Deleted search engines are still available. Manually added search engines are not available.

Reproducible: Always

Steps to Reproduce:
1. Start the latest nightly build with a clean profile
2. Close Shiretoko
3. Delete a search engine file (f.e. google.xml) in the program directory
4. Start Shiretoko
5. If you want to use the delete search engine or you want to manage the search engines you get an error
Actual Results:  
The error message occurs:

ASSERT: *** Search: _installLocation: engine has no file!
Stack Trace: 
0:ENSURE_WARN(false,_installLocation: engine has no file!,2147500037)
1:()
2:()
3:()
4:isDefault([object Object],0,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object])
5:SRCH_SVC_getDefault([object Object])
6:getDefaultEngines([object Object])
7:EngineStore()
8:engineManager_init()
9:onload([object Event])

Expected Results:  
- Deleted search engines (the xml file) sould be removed from the list
- New or updated search engines (in the searchplugins program oder profile directory) sould be updated in the list

I used the default theme.

I think that the bug is also present in other operating systems.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #0)
> Steps to Reproduce:
> 1. Start the latest nightly build with a clean profile
> 2. Close Shiretoko
> 3. Delete a search engine file (f.e. google.xml) in the program directory
> 4. Start Shiretoko

This isn't a supported operation, since there should be no reason to mess with the default search engines. I don't think we're going to add code to handle this case.

Comment 2

[mirko2324]

How can I add a search engine for all users of a firefox installation? Up to version 3.0.x I copied the engine file in the program directory and all users got automatically the engine. And when I deleted an engine file it was no problem because the search engine was removed from the list.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Oh, I see. Ideally you would do that using a DEX (along the lines of https://developer.mozilla.org/En/Repackaging_Firefox ) or globally installed add-on, which can also include search plugins (e.g. https://developer.mozilla.org/en/Bundles#Application-specific_Extension_Files and https://developer.mozilla.org/en/Adding_Extensions_using_the_Windows_Registry ), but that might be more complicated of a solution than what you're looking for.

I don't know offhand Firefox 3.1 is behaving differently, but the only major change to the search service since Firefox 3 is the introduction of a JSON cache for search plugins. Perhaps the deletion isn't triggering a rebuild of the cache and we're ending up setting the engine's file to the old, non-existent file.

Comment 4

[Ed Avis]

>This isn't a supported operation,

Surely, however, it should not trigger an assertion failure?  ASSERT should only be used for truly impossible conditions - not to check something environment-dependent such as whether a file exists.

I think the bug here is that ASSERT is being used to assert 'cannot ever happen' for a situation that does often happen.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #4)
> Surely, however, it should not trigger an assertion failure?

Indeed it shouldn't, that's why this bug is still NEW :) Bug 480737 fixed the cases where the file deletion occurs while Firefox isn't running, but this can still happen if you delete the file while Firefox *is* running.

It shouldn't be too hard to adjust the search service code to fail gracefully in these cases. Need to audit uses of _file that depend on it being existent... From a quick scan, I think the only uses that matter are in _serializeToJSON, _serializeToFile, and _remove. For _serializeToJSON, we can have it return null in that case, and adjust _buildCache to avoid having it add a null engine to the cache. I think _serializeToFile and _remove can just fail silently.