Closed Bug 231203 Opened 21 years ago Closed 21 years ago

Searchplugins no longer load

Categories

(SeaMonkey :: Search, defect)

Product:
SeaMonkey
Component:
Search
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: pbergsagel, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

Proposed patch
1.67 KB, patch
darin.moz
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review 
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.
Keywords: regression
Blocks: 172119
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.
OS: MacOS X → All
Hardware: Macintosh → All
Confirming as per Mat's comment
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Severity: major → normal
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.
Flags: blocking1.7a?
Flags: blocking1.4.2?
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.
Severity: normal → major
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 :)
URL: N.A. → http://mycroft.mozdev.org/
Summary: Searchplugins (downloaded from Mycroft Mozdev page) no longer load → Searchplugins no longer load
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.
Attachment #139799 - Flags: superreview?(jag)
Attachment #139799 - Flags: review?(darin)
*** 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
Attachment #139799 - Flags: superreview?(jag) → superreview+
> 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
Attachment #139799 - Flags: review?(darin) → review+
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Flags: blocking1.7a?
verified.
Status: RESOLVED → 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?
Flags: blocking1.4.2? → blocking1.4.2-
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: