Jump to content
  • Sign Up

a cry for help on the browser front....


Recommended Posts

Hi everyone,

This is a technical issue, but a really strange one with Chinese characteristics. Basically, a few people have been running into some trouble using my Chinese-English translation site with Firefox. I downloaded the browser to check myself and -- sure enough, it screws up the form submission. The problem appears to be a browser failure to pass along variables to the script.

I'm incredulous that this could be a software issue with Firefox since there isn't much mention of it abroad, and so am wondering if this is a product of filtering software somewhere malfuctioning or mangling the http request. I know the issue isn't standards-compliant HTML, since even Mozilla's own standards-compliant FORM doesn't work for me:


or mirred at


So here's my cry for help.... If there are people in China with Firefox installed or willing to download it, can you try one of the following above scripts (preferably the Mozilla one) and let me know (1) does it work and (2) if it does, what version of Firefox are you using?

I'd really like to make my site more accessible to Firefox users, but this has got me baffled....


Link to comment
Share on other sites

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

did you try URLencoding? it makes the chinese more "browser friendly" ... i'm trying to solve similar issues in firefox now ... (chinese characters don't appear in UTF-8 the way they should ...)

e.g., http://chinese.primezero.com/soleri/q.php?q=smile

after these kinds of bugs are fixed, we can move forward on promoting firefox heavily in asia...


neither this or that script shows what you want it to show... what are you trying to do? maybe i can help?

the characters appear normal over here, however...


and firefox does a good job here, as well ...


Link to comment
Share on other sites

here is a test of GET with firefox. (a preview of my advanced search feature). it works fine.

here is the test form...

> http://chinese.primezero.com/soleri/advanced_search_test.html

this is the sample get URL that results from submitting the form...

> http://chinese.primezero.com/soleri/t.php?w=english&q=test&s=english&ad=ASC

you can send your variable using the form ... you get your variables in PHP by doing this ...

$what = $_GET["w"];

does that make sense?

there is a 99% chance that the browser has nothing to do with the form. you cannot view this post without your browser forms being processed properly...

hope we can solve this...

Link to comment
Share on other sites

Attemps with both POST and GET under php were unsuccessful. IE and Mozilla handled them perfectly, but under Firefox the variables simply weren't passed along.

For what it's worth, Firefox also screws up on the formatting of the main page -- doing strange things like occasionally displaying hidden input fields, etc. I'm not sure if the problem is the immaturity of the browser of if something at the network layer is screwing around with things, but this experience is souring me on Firefox.

Link to comment
Share on other sites

I got curious and ran the adsotrans main page through the w3c validator (http://validator.w3.org/). After working past the fact that it couldn't handle the valid iso-2022-cn character set, it did find some things wrong on the page. This may not affect the get method, but may explain some of the weirdness in Firefox, which tries to be fairly strict in its HTML parsing. There were things like </center> with no <center>, </a> with no <a> etc.

I also threw together a cgi perl script that uses the get method and it works fine. I don't know what the problem is with the Mozilla test script and the adsotrans test script, which is no longer available.

Link to comment
Share on other sites

Thanks for the suggestion re: W3 validator. I should have thought of that myself, and will clean things up and see if the problems persist. I don't think this is an issue of HTML though.... particularly since the Mozilla test document fails to work.

There is no script behind the test page, which is just an example of standard HTML. Clicking the button will give you an error page -- but if you look at the location bar on the error page, you can see that the variables have been dropped instead of listed as expected.

Link to comment
Share on other sites

ok, here is a demo of the code below... in PHP ...



/* place this code in a file and call the file index.php */

@$w = $_GET['w'];

<form action="index.php" method=get>
<p>This form uses the get method properly.

<? echo "<input type=text name=w value='$w'>" ; ?> 

<input type=submit value="Test!">



if( strlen($w) ){
echo "you entered <b>$w</b> into the box, the variable is w and it is equal to <b>$w</b>.";
} else { 
echo "enter something, please ... (^_^) (_ _) (^_^)";


Link to comment
Share on other sites

I see that the HTML has been cleaned up and the page renders much better. As suspected, though, the GET method problem remains. I copied the HTML from the test page down to my own script and played with that. The HTML is of course fine. The problem is the ISO-2022-CN character set. If I change to another character set like gb2312 the data is sent as it should be. Firefox is supposed to support this charset, so I don't know why it isn't sending the characters. It is bugging me as a fan of Firefox so I posted a message to the Mozilla board to see what they say.

Link to comment
Share on other sites


A very deep thank you for helping figure this out. This goes out especially to geek_frappa and beirne. Thanks guys, I'm positive I wouldn't have tracked this down without your help. :)

Yes -- the problem turned out to be the character encoding. I'd set ISO-2022-cn as the server default because it is a superset standard that is supposed to simultaneously supports a variety of the older encoding methods. The standard isn't nearly as widespread as Unicode. I chose it because not specifying a Guobiao-compatible standard resulted in most browsers guessing the encoding wrong.

So Geek_Frappa -- I wouldn't question your decision to go with Unicode. I choose Guobiao out of convenience: the things I wanted to read were written almost exclusively in it and I wasn't terribly concerned about scalability when I started working on this. I don't think conversion is a really that big a deal though: if you need to support different character sets, try checking out the GNU utility "iconv" (libiconv). This is how I added Unicode support to Adso and is how -- one of these days -- I'm probably going to overhaul the entire thing into Unicode, which has a much bigger character space and is almost unquestionably a better standard.

So again -- thank you everyone. :)

Link to comment
Share on other sites

Join the conversation

You can post now and select your username and password later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Click here to reply. Select text to quote.

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...