User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040116 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040116 I installed the latest nightly (16 Jan 03) and reinstalled my search plugins. Upon launching Mozilla none of the plugins would load in the sidebar. Reproducible: Always Steps to Reproduce: 1.Installed the 16 Jan 03 nightly Mozilla suite. 2.Install searchplugins from an earlier nightly. 3.Search plugins fail to load upon launching Mozilla. Actual Results: Searchplugins fail to load when Mozilla is launched. I removed all the searchplugins except those which came with this nightly (Bugzilla@mozilla; dmoz.org; Google; AskJeeves; LXR@mozilla.org; mozilla.org) and they loaded when Mozilla was launched. **Note to test for this bug at least on of the plugins from the Mycroft searchplugin collection must be installed in the Searchplugins folder of Mozilla. Expected Results: Any plugin downloaded from the Mycroft page on Mozdev.org page should load into the Mozilla sidebar search panel. Note that the pre-installed searchplugins worked when this nightly is launched. All the search plugins failed when any other plugins from Mycoft are installed alongside the ones already installed. When the new search plugins from Mycroft are removed and Mozilla is relaunched the plugs reappear. Adding extra searchplugins from Mycroft fails; only the default set which comes with Mozilla will load and work.

Could someone please mark this bug as confirmed and change the hardware and OS to all. I can confirm the same problem exists with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040116 Plugins are downloaded correctly and show until you restart the browser. Once the browser is restarted, the new plugins do not show up in the list. The plugins do appear in the searchplugins folder as they are supposed to.

Confirming as per Mat's comment

NOTE, This issue appears in MozillaFirebird Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040117 Firebird/0.8.0+ as well.

only searchplugins with an icon in PNG format don't load. convert the PNG icon to GIF and the searchplugin will work fine.

There has to be something more to it than that. I have 25 search-plugins installed. None of the plugins with png images show up, but 16 of the search-plugins have gif images and only 6 of them show up. Also a plugin did not need an icon to show up in the list in the past, but now you need one. strange things start happening when you delete an image, I deleted just my googlefrance.gif file and five of the six that used to display stopped showing up.

Upon further inspection I agree. It is not the image format, but the extension. jpg, jpeg and png are all extensions that are supposed to be supported and are not working. If you rename the extension to gif it will work. Why some other plugins disappear when a plugin isn't showing up properly is a mystery. The check for the icons was changed in nsInternetSearchService.cpp on Jan 12, 2004, so I'm assuming this is what caused the issue. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsInternetSearchService.cpp&branch=&root=/cvsroot&subdir=mozilla/xpfe/components/search/src&command=DIFF_FRAMESET&rev1=1.200&rev2=1.201

I am downgrading this bug to Normal from Critical since there is an easy fix. Make sure all the image files for the search engines use the GIF image format. Also any search engines without an associated image file must be removed. I went through my 48 search plugins and made sure all the image files were in the GIF format and now they all load and perform searches. Matthew you have some good observations about the extension. We could close this bug we restrict the images just to GIF. Matthew do you feel this bug requires further resolution or can be closed as "worksforme" if the images are restricted to the GIF format?

I still think it is major. I would not call converting all these images an easy fix. A great number of search-plugins don't use GIF format. All of those plugins will now break Mozilla. Instead of fixing a few lines of code, it is a support nightmare. Site owners, users and developers won't know about this bug and will wonder why their plugins no longer work. Sherlock plugins will no longer work. Mycroft alone would need to change documentation, scripts, images and database entries for more than 500 plugins. A break down of todays search-plugin images at Mycroft: 539 are PNG 4 are jpg 267 are GIF GIF isn't even the most popular format. In my opinion, this is a regression that needs to be fixed.

I agree with Mat, this is a true regression and the fix is not easy. Nominating it for blocker. If it goes into the maintenance release 1.4.2, we bad off.

I wish I had the ability to fix the code in all ways intended, but I don't. All I can suggest is if the code can not be fixed, to back out the code that broke it. I believe that is the code provided by http://bugzilla.mozilla.org/show_bug.cgi?id=214797 I don't have the rights to change information in this bug, so I will offer my suggestions as to what needs to be changed about this bug in order to get it the attention it deserves. The summary should not contain everything in the parenthesis. It leads people to believe it is a Mozdev only issue. I do think "Searchplugins no longer load" describes the bug well though. The severity fits the definition of Major. It is a major loss of function when Mozilla-Search breaks the standard it was built on and can't use half the search-plugins that were built specifically for it. There is a work around for part of that, but it is ugly, not easy and nearly impossible to get all search-plugins providers to follow. The other major loss of functionality is the loss of compatibility with the Sherlock system and the plugins thereof. If you all disagree with me about the severity, I respect your opinion, but I have a question for you that might help you understand what is driving me to push for the change. If half the sites on the web no longer displayed in Mozilla because Mozilla was changed and could now only display data from web pages with .html extensions, but users could view the pages if they renamed the files to .html in their cache, would you call that bug Normal?

Comment #7 mentions an easy workaround. It is not easy and it causes a major loss of function. Upgrading to major. And it _is_ a regression. CCing Asa on this, since he cares a lot about search engines.

Mat, forgot to change the description of the bug. And I added the URL to mycroft, so that people can follow it in order to try it out. Any idea about the blocking flags? they are still set on "?" and nobody has plused or minused them. How can I have somebody look at them? I've CC-ed asa on this, but I'm not sure if that will get on his radar... About your permissions: ask somebody on IRC to grant you the following permissions: canconfirm Can confirm a bug. editbugs Can edit all aspects of any bug. You deserve them :)

Thanks for the changes and the IRC tip. Letting Asa know about this bug is good and I'm sure he will know what to do about the blocking flags. However, in addition to that, I'll mention the blocking issue on MozillaZine and see what comes back.

I've made my own investigation and come up with the same conclusion as Matt. The regression happened first on the *2004-01-12-08* build, the 2004-01-11-07 build was working well. Then I've checked bonsai for the changes between these 2 dates: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=01%2F11%2F2004+07%3A00%3A00&maxdate=01%2F12%2F2004+08%3A00%3A00&cvsroot=%2Fcvsroot The only checkin that affects the search component is the one caused by bug 214797 and affects 4 files: * mozilla/ xpfe/ components/ search/ src/ nsInternetSearchService.h * mozilla/ xpfe/ components/ search/ src/ nsInternetSearchService.cpp * mozilla/ xpfe/ components/ search/ src/ Makefile.in * mozilla/ xpfe/ components/ build/ Makefile.in The only changes that make sense to me and can cause this regression are in nsInternetSearchService.cpp: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/components/search/src&command=DIFF_FRAMESET&file=nsInternetSearchService.cpp&rev1=1.200&rev2=1.201&root=/cvsroot I've written to neil@parkwaycc.co.uk in order to have him look closer at his code and tell us what's wrong.

It's not actually my code, but the issue was caused by that patch - the old function implicitly checked for path existence but the new function requires that you check the path exists before you check for file existence.

*** Bug 231433 has been marked as a duplicate of this bug. ***

I've looked through the patch and found this: temp = Substring(uri, 0, uri.Length()-4); I beleive this is not a correct way to cut the extension from the end of URI since extensions may be more than 3 characters long. As a real life example JPEG AFAIR by spec allows extensions like '.jpeg', '.jfif'. So I propose something like ths instead: for(int i = uri.Length()-1; i >= 0 && uri[i] != '.'; i--) { //do nothing } if (i >= 0) { temp = Substring(uri, 0, i); } else { temp = uri; //uri without an extension is also valid }

Ivan: I think you misunderstand the code. The |uri| variable points to a search file that must end in ".src" (see the code about 20 lines above the code you quoted), so at this point in the code we know the extension including the period is 4 characters and this code can safely chop it off.

Comment on attachment 139799 [details] [diff] [review] Proposed patch sr=jag

> The |uri| variable points to a search > file that must end in ".src" (see the code about 20 lines above the code you > quoted) Oh... My bad. I've looked at the patch only. Sorry!

*** Bug 232179 has been marked as a duplicate of this bug. ***

Can confirm that plugins disappear in nightlies for OS X as late as 01-26-04, have reverted to 01-02-04 as suggested in another similar bug report, which does retain search plugins (build Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040102 Firebird/0.7+)

Comment on attachment 139799 [details] [diff] [review] Proposed patch r=darin

Fix checked in.

verified.

*** Bug 232677 has been marked as a duplicate of this bug. ***

Nothing that even resembles this code is on 1.4 branch. Is anyone sure it fails there?