Status

SeaMonkey
Search
--
minor
RESOLVED INVALID
14 years ago
6 years ago

People

(Reporter: David Aznar Reguero, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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:
(Reporter)

Comment 1

14 years ago
Created attachment 138162 [details]
google.src update

Comment 2

14 years ago
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 3

14 years ago
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.
Attachment #138162 - Flags: review-
(Reporter)

Comment 4

14 years ago
Erich 'Ricky' Iseli wrote:
> 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.

Results are not parsed but there are more bugs fixed in this file.

> 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.

I consider it more like spyware. This should be optional at least.
And there's already a field called HTTP User-Agent that does that!

> 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/

The problem is that the purpose is to reload every x days and the code
you are getting is not signed I don't like my machine running any non
signed code by trusted people even if it's javascript.

> Otherwise, I agree with you that the encoding should be passed to the search
> engine too.

The encoding was already passed. This update just sends it like google
does uppercase, it worked before but I don't want any problems.
(Reporter)

Comment 5

14 years ago
timeless@bemail.org 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.

Comment 6

14 years ago
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.

Comment 7

14 years ago
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.

Comment 8

14 years ago
Is the google.src at mozdev newer than the one supplied with Mozilla?

Comment 9

14 years ago
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

Comment 11

14 years ago
Resolving based on comment 9.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.