Well, our back-end developer found a way to fix the problem on his
end. Once I find out what he fixed to get the ajax working in FF3, I
will post again.
Thank you everyone for your help!
On Sep 11, 4:02 am, Karl Hungus
wrote:
> I reckon you're right Nick - I'm reasonably certain that is the
> p
I reckon you're right Nick - I'm reasonably certain that is the
problem. We are using a quite old Java content management system at
the server end, and I've already found one place where the direct
comparison you mentined is made, so I'm guessing there could well be
others within the package itsel
2009/9/10 Karl Hungus :
>
> I can see the form data in the body of the post too, using both Live
> HTTP Headers and Charles. Which I guess only confuses me more. :-)
>
> One thing I did notice, is the Content-Type attribute of the request
> header has "application/x-www-form-urlencoded; charset=UT
I can see the form data in the body of the post too, using both Live
HTTP Headers and Charles. Which I guess only confuses me more. :-)
One thing I did notice, is the Content-Type attribute of the request
header has "application/x-www-form-urlencoded; charset=UTF-8" for FF3,
but only "application
> If the body of the request contains the form data then the problem is
> on the server; if not, then the problem is on the browser. If the
> problem is on the browser then more digging will be required, but if
> it's on the server then the information about the whole request
> (headers and body)
> If the body of the request contains the form data then the problem is
> on the server; if not, then the problem is on the browser. If the
> problem is on the browser then more digging will be required, but if
> it's on the server then the information about the whole request
> (headers and body)
2009/9/9 RPrager :
> FF3 output:
>
> logcgisCan not access CGI data: Script can only
> be used to decode form results
> There are 0 positional parameters and 0 CGI fields
>
>
> FF2/IE output:
>
> logcgis
> There are 0 positional parameters and 2 CGI fields
> CGI 'F10' equals 'Yes'
> CGI 'F11' eq
It's not possible to tell what's going on without knowing what code is
determining which request parameters are "CGI" parameters and which
aren't. However it seems pretty clear that whatever is doing that is
probably making some bad assumptions about HTTP.
On Wed, Sep 9, 2009 at 10:11 AM, RPrage
Well I tried unchecking "Show XMLHttpRequests" and the problem didn't
go away.
I also tried from a different machine with FF3 but no firebug. It
didn't work on that machine either.
I've been in contact with the back-end developer and he created a
short c program to test this problem.
Here's the
Also try it from a different machine with FF3 but no firebug
installed. I have noticed on occasion, that firebug hangs up and does
not allow any ajax requests to go through.
On 9/8/09, Karl Swedberg wrote:
> I was having ajax problems with a certain combination of Firefox 3.5.x
> and Firebug. Ca
I was having ajax problems with a certain combination of Firefox 3.5.x
and Firebug. Can't remember which versions exactly, but I do recall
that unchecking the "Show XMLHttpRequests" option in the Console tab
made the problem go away.
--Karl
On Sep 8, 2009, at 2:41 PM, Mike McNally wrote:
For what it's worth, I have a whole application that works just fine
with AJAX form posts from FF3, and I didn't have to do anything at all
to make it work. It'd be interesting to learn what back-end software
is involved (Java/Stripes in my case).
On Tue, Sep 8, 2009 at 12:03 PM, RPrager wrote:
Mine won't even work in FF3 if I use the GET method. I'm currently
working with the developer to get to the bottom of this. I will post
if I find a solution. In the meantime, keep the suggestions coming if
you have them. Thanks!
On Sep 8, 5:19 am, Karl Hungus
wrote:
> Yes - me. Exactly the same
2009/9/4 RPrager :
>
> Here is the only difference I found in the Request Headers:
>
> FF2: Content-Type application/x-www-form-urlencoded
>
> FF3: Content-Type application/x-www-form-urlencoded; charset=UTF-8
>
> Any ideas?
One definite possibility is that the server-side component is fail
Yes - me. Exactly the same problem as you. FF3.x not liking an Ajax
form post.
It works if I change the POST to a GET, but that is a bit pants to be
honest. I suspect its a FF3 issue, but don't know what.
Did you get to the bottom of it ?
Rgds,
KH.
On 4 Sep, 17:20, RPrager wrote:
> I'll see
I'll see if I can take a look at server log files. Has anybody else
experienced problems using ajax with FF3? Any other ideas are
appreciated. Thanks
On Sep 4, 10:10 am, Mike McNally wrote:
> Well frankly that's not looking like a jQuery problem to me. Your
> *server* is returning different res
Well frankly that's not looking like a jQuery problem to me. Your
*server* is returning different results. I have no idea why, but I
don't see what jQuery (or anything else at the client) is supposed to
do about that. Do you have debug logging or other debug facilities at
the server to see what
Here is the only difference I found in the Request Headers:
FF2: Content-Typeapplication/x-www-form-urlencoded
FF3: Content-Typeapplication/x-www-form-urlencoded; charset=UTF-8
Any ideas?
On Sep 4, 9:47 am, RPrager wrote:
> Firefox 3 response:
>
> Not available at present
> Status c
Firefox 3 response:
Not available at present
Status code = NL
According to our back end developer, the NL = 'Null execution'.
Meaning that the page (newcoleng) was launched without any input at
all.
I.e., neither a nor any positional parameters. The page is at a
loss as to how to serve my need
Well what exactly is the error? What is different about the server
response from FF2 vs. FF3?
On Sep 3, 9:04 pm, RPrager wrote:
> I've been using Firebug. The data that my browser is sending looks as
> expected.
>
> Here is the information from firebug:
>
> Response Headers
> Date: Fri, 04 Sep
I've been using Firebug. The data that my browser is sending looks as
expected.
Here is the information from firebug:
Response Headers
Date: Fri, 04 Sep 2009 01:54:24 GMT
Server: Apache/2.2.6 (Fedora)
Content-Length: 179
Connection: close
Content-Type: text/html
Request Headers
User-Agent
You **must** install and use something like Firebug or TamperData to
see what your browser is sending to the server, and what your server
is sending back. Just because the HTML response content looks like an
error does not necessarily mean that the HTTP response contained an
error code (for exampl
I just tested this code using FF2 and it works just fine. This appears
to be a FF3 problem only. I'm currently using Firefox version 3.5.2.
Any ideas?
On Sep 3, 10:31 am, RPrager wrote:
> Thanks for the idea but adding (dataType: 'text') did not produce a
> different result.
>
> On Sep 3, 9:32 a
Thanks for the idea but adding (dataType: 'text') did not produce a
different result.
On Sep 3, 9:32 am, 月讀 wrote:
> My english is not well.
>
> $.ajax({
> type: "POST",
> url: "newcoleng",
> data: "F10=Yes&F11=No",
> dataType: 'text',
> success: function(
My english is not well.
$.ajax({
type: "POST",
url: "newcoleng",
data: "F10=Yes&F11=No",
dataType: 'text',
success: function(data){
alert( "Data Saved: " + data );
}
});
Try it.
The url of the call is in the same domain.
I added the error property but it still always comes back a success in
both FF and IE.
On Sep 3, 8:09 am, gil wrote:
> The url of the call it's in the same domain? Because, FF does allow
> cross domain.
>
> Also, try adding the error property, to see t
The url of the call it's in the same domain? Because, FF does allow
cross domain.
Also, try adding the error property, to see the message.
On Sep 2, 3:58 pm, RPrager wrote:
> Hello Everyone,
>
> I'm fairly new to using ajax with jQuery and I'm having an issue in
> firefox. Here's my ajax call:
27 matches
Mail list logo
