User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: This google.src update contains: - removed unused field <input name="sourceid" value="mozilla-search"> - removed dangerous update url: update="http://www.google.com/mozilla/google.src" updateCheckDays=1 - update ie and oe to UTF-8 as google is using when searching directly in the web page. - Make the sidebar display results again. Reproducible: Always Steps to Reproduce:
What is this bug about? As it looks like, results are not parsed. Then the subject should be "Google search plugin doesn't parse results in sidebar" or something similar. Then you can attach the patch with corrects this problem. About the mozilla-search field: this is not unused! It's used by all search plugins and the goal of this additional field is to notify the search engine owners that there are people out there using Mozilla. Consider it a kind of evangelization. The update URL is not "dangerous", it should just be changed to where the original google plugin is stored. That can be http://mycroft.mozdev.org/ Otherwise, I agree with you that the encoding should be passed to the search engine too.
Comment on attachment 138162 [details] google.src update Please make a cvs diff and please provide *some* update url. If you want to use an lxr url instead of a www url that'd be fine. http://lxr.mozilla.org/seamonkey/source/xpfe/components/search/datasets/google. src?raw=1 Should work. If you're going to do that then change the update frequency to something closer to 30 days. I need to check the update code, I bet it sucks on well configured systems.
email@example.com wrote: > (From update of attachment 138162 [details]) > Please make a cvs diff and please provide *some* update url. I'll wait for some of your comments. > If you want to use an lxr url instead of a www url that'd be fine. > > http://lxr.mozilla.org/seamonkey/source/xpfe/components/search/datasets/google.src?raw=1 > > Should work. If you're going to do that then change the update frequency to > something closer to 30 days. > > I need to check the update code, I bet it sucks on well configured systems. As I said I don't want to use non signed code. I don't like some cracker sending me a broken google.src that makes google search stop working. Could you comment what's the usefulness of the update code? I don't expect google changing the google HTTP search API in many years to follow, and if they change I'd expect they'll also like to make any google.src stop working.
First of all, the format of this file is borrowed from the sherlock specification. The update section is extremely important: if google, or any other search engine, changes a little bit of the code, then the plugin has to be updated accordingly. Asking everyone to download the new plugin is overkill, updating it automatically is more than useful. Maybe google won't change the output code of their search results anytime soon, especially since they have the very useful comments. But what if they do? And we're not talking in the conditional, since from the 700+ search plugins available at the mycroft repository, a significant part of the plugins have to be updated after 3 months. Of course, it would be better to be able to sign the code. But: - are any extensions signed? no - are any search plugins you download from mycroft signed? no If you are downloading mycroft plugins http://mycroft.mozdev.org/ , then you trust the source. Having an update tag in that file, pointing to the very file you've just downloaded, is just a continuity of this trust. Nobody is going to send you a broken plugin updating a working one that's just paranoia. The difference between the HTTP user agent and the special field is that the user agent just tells what browser you are using, while the special field tells the provider that the search plugin is used. That's an important difference since part of our advocacy is: "please provide some comments in your results, so that parsing is more easy, even if you change your code". Of course, often they will answer the part of search plugins users is insignificant, but nevertheless, this user share is going to increase as usage of Mozilla increases.
By the way, just noticed this: Why do you use tags for delimiting the search result, when google provides such useful comments? You: resultListStart="</table><p>" resultListEnd="<div class=n>" resultItemStart="<p class=g>" resultItemEnd="<font size=-1>" The google plugin located at mycroft http://mycroft.mozdev.org/plugins/google.src : resultListStart="<!--a-->" resultListEnd="<!--z-->" resultItemStart="<!--m-->" resultItemEnd="<!--n-->" Another problem I notice with your plugin is the charsets utf-8 in lowercase. Read bug 62409 and our documentation here: http://mycroft.mozdev.org/deepdocs/searchtag.html#queryEncoding it should be in upper case UTF-8. The google plugin at mycroft is perfectly working. I'm wondering why you are reinventing the wheel.
Is the google.src at mozdev newer than the one supplied with Mozilla?
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/components/search/datasets/google.src 1.3 May 13 2003 1.2 Mar 21 2002 1.1 May 24 2000 http://mycroft.mozdev.org/source/browse/mycroft/www/plugins/google.src 1.4 Nov 11 2003 1.3 Jun 28 2002 1.2 Jun 15 2002 1.1 Jan 31 2002 http://sherlock.mozdev.org/source/browse/sherlock/www/Attic/google.src 1.1 Dec 18 2000 As you can see the version 1.1 on mozilla.org is the same as the initial version of mozdev. But from then on, they started to evolve their own way: on mozilla.org very conservatively, on mozdev in a very progressive way. So you cannot say A is older than B, but only A and B are different. As of my testings, both work, so there's no need to change the parsing delimiters.
> - are any extensions signed? no xpi packages can be signed
Resolving based on comment 9.