Searchplugin disappears permanently after uninstalling extension with the same named plugin bundled

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Search
P1
major
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: Max, Assigned: rflint)

Tracking

({verified1.9.1})

3.5 Branch
Firefox 3.6a1
verified1.9.1
Points:
---
Bug Flags:
blocking-firefox3.5 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.10) Gecko/2009042700 SUSE/3.0.10-2.1 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

This only works for Firefox 3.5b4 (and probably previous betas too). If you install an extension, which provides a search plugin that is already present by default, and then disable or uninstall that extension, the search plugin disappears from the search bar.

Reproducible: Always

Steps to Reproduce:
1.Install a testing extension that provides a search plugin already present by default (<ShortName> must be the same)
2.Disable or uninstall this extension. Then restart browser of course.

Actual Results:  
Preinstalled search plugin is gone from the quick search bar.

Expected Results:  
Browser should have restored the original search plugin, located in the searchplugins subdirectory of the installation path.

Works on linux and windows builds (and, I believe, on mac too).
(Reporter)

Comment 1

9 years ago
Created attachment 375470 [details]
A testing extension

A testing extension which provides a Yandex quicksearch plugin replacing the preinstalled one.
(Reporter)

Comment 2

9 years ago
Attached extension should be tested on builds with Yandex search plugin preinstalled (russian for example).
(Reporter)

Updated

9 years ago
Version: unspecified → 3.5 Branch

Comment 3

9 years ago
(In reply to comment #0)
> .....
> Works on linux and windows builds (and, I believe, on mac too).

Mac OS: confirmed
Confirming, based on comments, asking for blocking Firefox 3.5. This bug affects at least users of Yandex.Bar extension.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3.5?
Haven't had a chance to look into this yet, but this might be a regression from bug 394979. I suspect we're only including the addon engine in the JSON cache when it's installed, and then not invalidating the app cache when it's uninstalled. Perhaps we should invalidate all caches when any of them change...
Assignee: nobody → rflint
Flags: blocking-firefox3.5? → blocking-firefox3.5+
(Reporter)

Comment 6

9 years ago
2 Gavin: exactly, this relates bug 394979. Setting the preference "browser.search.cache.enabled" to false fixes this issue.
Flags: blocking-firefox3.5+ → blocking-firefox3.5?
Ryan: you can haz blocker!
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [eta 5/12]
Created attachment 377147 [details] [diff] [review]
WIP
Whiteboard: [eta 5/12]
Target Milestone: --- → Firefox 3.6a1
Whiteboard: [has wip patch][needs status update]
Created attachment 378282 [details] [diff] [review]
Patch
Attachment #377147 - Attachment is obsolete: true
Attachment #378282 - Flags: review?(gavin.sharp)
Whiteboard: [has wip patch][needs status update] → [has patch][needs review gavin]
Created attachment 378760 [details] [diff] [review]
Branch patch
Attachment #378760 - Flags: review?(gavin.sharp)
Created attachment 378790 [details] [diff] [review]
Patch v2
Attachment #378282 - Attachment is obsolete: true
Attachment #378760 - Attachment is obsolete: true
Attachment #378790 - Flags: review?(gavin.sharp)
Attachment #378282 - Flags: review?(gavin.sharp)
Attachment #378760 - Flags: review?(gavin.sharp)
Comment on attachment 378790 [details] [diff] [review]
Patch v2

-modifiedDir wants || instead of &&
-remove "locale" temporary, move buildID to above rebuildCache definition
-if you're going to keep cacheEnabled, you might as well check it before calling _buildCache to avoid a pref check
-"let dir" instead of "let file" makes the diff smaller :)
-why |for each| for _loadEnginesFromCache() but forEach() for _loadEnginesFromDir?
Created attachment 378801 [details] [diff] [review]
Patch v2.1

(In reply to comment #12)
> (From update of attachment 378790 [details] [diff] [review])
> -modifiedDir wants || instead of &&
done

> -remove "locale" temporary, move buildID to above rebuildCache definition
done

> -if you're going to keep cacheEnabled, you might as well check it before
> calling _buildCache to avoid a pref check
done

> -"let dir" instead of "let file" makes the diff smaller :)
done

> -why |for each| for _loadEnginesFromCache() but forEach() for
> _loadEnginesFromDir?
cache.directories is an object, loadDirs is an array.
Attachment #378790 - Attachment is obsolete: true
Attachment #378801 - Flags: review?(gavin.sharp)
Attachment #378790 - Flags: review?(gavin.sharp)
Created attachment 378805 [details] [diff] [review]
Patch v2.2
Attachment #378801 - Attachment is obsolete: true
Attachment #378805 - Flags: review?(gavin.sharp)
Attachment #378801 - Flags: review?(gavin.sharp)
Attachment #378805 - Flags: review?(gavin.sharp) → review+
Comment on attachment 378805 [details] [diff] [review]
Patch v2.2

s/aCacheDir/aCachePath/ ?

Could use some more comments to explain what's going on, but we can do that in a followup.
Created attachment 378812 [details]
IRC transcript of patch discussion
Whiteboard: [has patch][needs review gavin]
http://hg.mozilla.org/mozilla-central/rev/c832d8634f23
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f9fdf276d414
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Verified on trunk and 1.9.1 with builds on Windows:

Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2a1pre) Gecko/20090525 Minefield/3.6a1pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: fixed1.9.1 → verified1.9.1
Blocks: 741802
You need to log in before you can comment on or make changes to this bug.