Closed Bug 277486 Opened 20 years ago Closed 10 years ago

google.com - searches from Chinese IPs including "client=firefox*" without Google language pref set to English redirect without keeping the search query intact

Categories

(Tech Evangelism Graveyard :: English US, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: walter, Unassigned)

References

Details

Attachments

(1 file)

When I use the Google search in Firefox 1.7.5 (and 1.7.3 previous to my recent
upgrade) I end up on a Simplified Chinese google search page
(http://www.google.com/intl/zh-CN/ - my IP is in China and Google is doing some
GeoIP lookups I guess, as my HTTP 'Accept-language:' is 'en') instead of my
expected search results.
Attached file my google.src
No manual editing - vanilla as installed by Fedora Core 3 + yum update (which
updated Firefox to 1.7.5).
First of all, Firefox is at version 1.0, Mozilla Suite is at version 1.7.5.
Second, if google is doing a redirect, then there isn't much Mozilla or Firefox
can do about it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Component: Search → General
Product: Firefox → Mozilla Application Suite
Resolution: --- → INVALID
Version: 1.0 Branch → unspecified
*** Bug 277487 has been marked as a duplicate of this bug. ***
Attempting to re-assign to Firefox and re-open.  Unsure if this will work.
Status: RESOLVED → UNCONFIRMED
Product: Mozilla Application Suite → Firefox
Resolution: INVALID → ---
Setting as a 'search' component bug.
Component: General → Search
I will post an ethereal dump of the network traffic shortly.
Walter, please listen to what I'm saying here. Firefox is at version 1.0, and
*Mozilla Suite* is at version 1.7.5. You have the Mozilla Suite, not Firefox.
They are not the same thing.

Secondly, my comment above still applies. There is nothing Mozilla Suite can do
about a Google server side redirect.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Component: Search → General
Product: Firefox → Mozilla Application Suite
Resolution: --- → INVALID
Seems to be related to bug 268763, bug 269154 and bug 270825.
Component: General → Search
Product: Mozilla Application Suite → Firefox
Walter, please stop modifying this bug. And read my previous comments.
Component: Search → General
Product: Firefox → Mozilla Application Suite
Re-opening as Gavin seems to be wrong.

My Help|About reads 'Firefox 1.0', with the User-agent Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0.  There is no inbuilt mail.
Status: RESOLVED → UNCONFIRMED
Component: General → Search
Product: Mozilla Application Suite → Firefox
Resolution: INVALID → ---
This is the conversation (copied from 'follow TCP stream' in Ethereal).

GET
/search?q=searchterm&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official
HTTP/1.1

Host: www.google.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111
Firefox/1.0

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en

Accept-Encoding: gzip,deflate

Accept-Charset: UTF-8,*

Keep-Alive: 300

Connection: keep-alive

Cookie: PREF=ID=24009bdcd3904f79:NW=1:TM=1105083061:LM=1105083061:S=NGazX-MCgyaiZjLn



HTTP/1.1 302 Found

Location: http://www.google.com/intl/zh-CN/

Content-Type: text/html

Server: GWS/2.1

Transfer-Encoding: chunked

Content-Encoding: gzip

Date: Sat, 08 Jan 2005 02:05:15 GMT

Cache-Control: private, x-gzip-ok=""
Let me understand this. You searched bugzilla, found a bug that described your
problem, then proceeded to file two new bugs?

*** This bug has been marked as a duplicate of 268763 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
I copied out the URL from the pasted ethereal dump and played with the values -
it seems that the search works if the client=firefox-a argument is left out.

I played with the value and it seems that client=firefox* will break the search,
returning the Chinese search page with no results.  client=anythingelse will
work fine, as does excluding the client.

To be clear:
 firefo works
 firefox fails
 firefox-a fails (original request being generated by search bar)

Some weird logic there @ Google.

I guess the client name must be changed as a short-termworkaround.  Where can I
do this?

Medium term, perhaps inquire at google as to why this happens?
Re-opening.  It is not clear that this is a duplicate. 

Why?  My search bar never worked, even on a fresh install.  This is different to
other bug descriptions.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
*** Bug 268763 has been marked as a duplicate of this bug. ***
*** Bug 269154 has been marked as a duplicate of this bug. ***
(In reply to comment #14)
> Re-opening.  It is not clear that this is a duplicate. 
> 
> Why?  My search bar never worked, even on a fresh install.  This is different to
> other bug descriptions.

No, it is not any different than those two bugs. It's the exact same bug. If it
makes you any happier, I'll dupe those ones to this one, since you actually
managed to provide some useful information while ignoring me. Thanks for the
detailed report, but next time, please be a little more receptive to the other
comments.
Component: Search → General
Product: Firefox → Mozilla Application Suite
Product: Mozilla Application Suite → Firefox
Component: General → Search
If I manually set Google to 'Google.com in English' then the search bar works
straight away with no code changes.  I suppose this has to do with a cookie. 
This may explain working/not working as described in related bugs.  

So, a short-term workaround for users is just to click 'Google.com in English'
then retry their search.

(I wonder if this bug exists in non-Chinese locales?)

PS to Gavin: I thought you were wrong, I stated my reasons.  I spent a lot of
time filing out this bug report here for the common good.  You spent a lot of
time repetitively closing my bug, or claiming it was INVALID.  It is not so
heartening for a first-time bug reporter to see their genuine bug filed as
invalid instead of intelligently reclassified.  I came here for the common good
after developers on my distribution suggested taking it 'upstream'.  Also, In
case it's not clear from my comments, I would not have posted the bug again if I
was aware that an 'invalid' bug apparently posted under the wrong product could
be reclassified all the way to the right product and component.

(Bugzilla is more powerful than I expected! .. but its interface is less than
intuitive in this case.  Also, it required reposting to the 'General' component
before changing to 'Search' as far as I could see.  But that's a Bugzilla bug!).

I'd just like to say I'm still unsure why you've reposted the bug under 'Mozilla
Application Suite' instead of Firefox, when my Help menu says 'About Mozilla
Firefox' and that dialog reads 'Firefox 1.0'.  If you are correct in moving this
bug from Firefox to 'Mozilla Application Suite' then it would appear that there
are some major naming/name display problems in the software that would be
impacting on more than just this one bug report.
Emailed webmaster@google.com explaining the issue and received ticket #19236980.
Google 1st-round reply:

"Thank you for your note. It's possible that uninstalling and re-installing
Firefox will resolve the problem you're experiencing. If this doesn't
solve the problem we suggest deleting your cache and cookies, rebooting,
and then contacting the support department at Firefox.

We're sorry we can't be of additional assistance."

I replied and pointed out that only in the case that one actually clears cookies
and/or re-installs would one encounter the problem, re-iterated that clicking
'Google in English' fixes the problem, but that is not a solution for Google's
Chinese customers using Firefox.

Awaiting further correspondance.
Chinese pages can't be displayed at all!!!
*** Bug 286886 has been marked as a duplicate of this bug. ***
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → EXPIRED
Nope. I think it is still valid in en1.5b2+zh_CN xpi. As zh_CN1.5b2 is using 
completely different search engines, it doesn't affect the users.
It seems basically the google site is just redirecting users in China (perhaps
in other places / everywhere?) if they dont have the  preference cookie set up yet.

The cookie was set on my machine by going to google search preferences looks
like this:

Name: PREF
Content:
ID=e56541b04b657fb8:FF=4:LD=zh-CN:NR=20:CR=2:TM=1129250008:LM=1129362861:S=KuEdSmh3xq_6ZbAt
Domain: .google.com
Path: /

I suggest the searchbar code checks if this is set, if not generates a similar
cookie or launches a popup explaining that searches may not work until you go to
google prefs and set your preferences.

Once that's done, a search in Chinese characters works fine.

This is the case on my Firefox -- Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7.12) Gecko/20050915.

I can verify it on the latest if someone would find that useful... though please
try yourself first.
 1. Tools | Options | Privacy | Cookies | View Cookies
 2. Find the google.com PREF cookie + delete it.
 3. Try immediately a search from the google option in the firefox searchbar.

Tentatively re-opening this as I'm not positively sure it's gone in the latest
release... please mark RESOLVED again if its gone.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
i can confirm it in firefox 1.5beta2, english, windows. with china ip,
lang=zh-cn. remove client= helps anyways (or change it to clientid=)
Is this still reproducible? It seems to me google have changed
"client=" handling since then.
> It seems to me google have changed "client=" handling since then.
Changing means don't work still.
(In reply to comment #29)
> > It seems to me google have changed "client=" handling since then.
> Changing means don't work still.
> 

So what is the expected result? I'm afraid this is not a searchbox/internetsearch
problem. This should be assigned to the chinese l10n team.
"So what is the expected result?"
 The search works.

"What happens?"
 You get a blank google home page.

"I'm afraid this is not a searchbox/internetsearch problem."
 I disagreee.

It seems to me that the code to change IS in the searchbox - you need to make sure the language preference cookie is set.  Otherwise the search box will fail to work, and only produce blank pages, until the user manually sets a google language preference.

Google doesn't seem to care as they haven't bothered corresponding.
I am the victim of this bug too.  I sniffed on the wire and found that the URL Firefox sent was like:

http://www.google.com/search?q=searcg+string&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official 

The offending part is `client=firefox-a'.  Without it all is OK.  With it I am always redirected to the Google Chinese home page.

I think Google might be to blame.  However, it is just annoying the search does not work.  Is there a quick way to disable `client=firefox-a' from sending?  It is really not in google.src.  Some people say the problem is in searchconfig.properties (in browser.jar).  Any better way than manually modifying it?
Sorry that I did not test the mentioned hack in the last comment.  To work around the problem, you may do this:

1) unzip /path/to/chrome/browser.jar in some temporary directory
2) edit content/branding/searchconfig.properties and comment out the second and third line
3) back up the original browser.jar
4) zip -r -0 browser.jar content
5) copy browser.jar /path/to/chrome/browser.jar

Now Google Search should work!
Okay, I'll try *once* to put this bug where it might actually be fixed. It's not a bug in Firefox search, the "client=firefox-a" is added at Google's request and as a part of Mozilla's partnership with them, and we can't just remove it, or create fake cookies or popups based on a website's errors even if that site is Google.

They, however, can stop redirecting without including the query part of the request, which is the bug here: no matter where they redirect, they need to not strip off the search query.
Assignee: p_ch → english-us
Status: UNCONFIRMED → NEW
Component: Search → English US
Ever confirmed: true
Product: Firefox → Tech Evangelism
QA Contact: search → english-us
Summary: Google searches result in blank Google main page → google.com - searches from Chinese IPs including "client=firefox*" without Google language pref set to English redirect without keeping the search query intact
Another (better) work-around for this `bug':

1. Go to www.google.com (presumably you get www.google.com/intl/zh-CN/).
2. Click on the link `Google.com in English'.
3. Optionally click on `Preferences' to set your language preferences, which will now not be affected by your IP.
4. Done!
Closing as INVALID.
Status: NEW → RESOLVED
Closed: 19 years ago10 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: