User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021015 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021015 Works fine in netscape. Mozilla locks up when using buy.com search plugin. All builds before 20021003 worked fine. FYI: Mozilla does not lock up on search of buy.com if search plugin is not installed. Reproducible: Always Steps to Reproduce: 1. Install buy.com search plugin. 2. Perform search on buy.com. Actual Results: Mozilla locks up. Does not respond. Expected Results: Display search results in sidebar and not lock up.
Created attachment 103003 [details] Mozilla locked up and system guard info. Screen shot of Mozilla locked up after search with system guard info.
Confirmed on Mozilla for Mac OSX BuildID: 2002100911
Thanks Joolz, but removing those characters screws up the categories. Also, this plugin is not alone in this issue. I'm having the same problems with the whatis.com plugin that I'm trying to update, I've taken out any special characters and it still locks up. On October Third some changes were made to nsInternetSearchService.cpp See http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&file=mozilla/xpfe/components/search/src/nsInternetSearchService.cpp&date=month The fixes concerned memory leaks, I think the memory leak fix somehow broke these plugins. I tested the plugins with builds prior to October third and they work, but all builds after October third lock up. These plugins do have some things in common. They both have two interpret "result" sections, one interpret "category" section and a large amount of results. I'm guessing since your testcase is using the category tag it may have something to do with that or the amount of results. Will continue testing to confirm.
I'm thoroughly confused. I got the whatis.com plugin to finally work, it has several more interpret sections now. Couldn't confirm what needed to be changed to stop the lock ups. Doesn't appear to be specific to interpret "category" sections.
this might be a dupe of bug 175324, but I seem to be too stoopid to use additional search plugins. If someone here builds from source, you can try out the patch from bug 175324 to see if it helps.
Andrew Schultz, to test another plugin (like the 2 attached to this bug), just save them with a name like "pluginname.src" into your searchplugins folder of the Mozilla installation. I think that's much easier than to build from source (thing which I haven't ever done) :( I'd be happy if you - or anyone else could confirm this is the same issue.
well then, I guess I'm not stoopid, because I'm pretty sure that's what I did. The "search" feature just didn't kick in when I did a search on buy.com.
Andrew: did you restart mozilla after you installed the plugin?
yup. I was trying the build from source. I'll try the .mozilla.org binary build when I get a chance.
ok, I got it working. the problem is the same as in bug 175324 the start is found, but not the end. end is reset to the stopindex, which is before start. marking dupe *** This bug has been marked as a duplicate of 175324 ***