When I'm using Firebug 1.5, I'm getting 200 ABORTED errors on certain ajax requests. You can see this happen on this demo page by typing into the textfield. The functionality of the site seems to work just fine even with these errors. Is it safe to simply ignore these errors?
This wicket mailing list thread seems to indicate that the wicket ajax code is doing what it should. Also, this firebug issue seems to indicate there may be some concern. Not sure what to think.
I just spent 30 mins with a similar problem. While this is not an answer directly to the above, a google search for my problem got me here, so I thought I'd add it here in case it saves someone else some time. As always, my problem turned out be developer error. I was binding an ajax request to a submit button, but I'd forgotten to use preventDefault() on the button before making the XHR, so the request was being aborted as soon as the default behaviour for the button kicked in - sometimes before the response came back, sometimes not - but it would always report in firebug 1.5 to be aborted.
I am also encountering this. I can see it on your demo site above on every request, but also I see it on one of my sites. I didn't notice this before, and I am sure I would notice it since I stare at the console for hours everyday. Gives some pretty mixed messages.
I am using a mac with firebug 1.5. This bug has been reported on the firebug bug list id=2712 but seems to be going nowhere. It's a tricky one. I tend to notice it when i have 2 simultaneous requests fired off at the same time, and perhaps one preemptively returns before the other. But this shouldn't cause an Abort message.
Sounds like aborts on requests that already were coming back with an OK. Firebug will filter these out on some future release, see the code change here:
http://code.google.com/p/fbug/source/detail?r=6127
I saw your demo page with firebug and seems to be working fine, there is no error to it and note that 200 response denotes that request went successful -> OK, it is not an error abort like you say. Thanks
Related
I'm having an issue with FineUploader in IE11. My page works fine when I upload files after the initial load with no issues at all for any files. However, if I leave the page open for 5 minutes without any activity, the next time I try to upload a file, it fails. In the Developer Tools, all I see for the upload request is (Pending...) for protocol, method, and result. Sometimes, it will freeze the browser completely, but other times, it just says "Processing..." on the screen. This is a Ajax POST call. Any ideas?
The "processing..." message indicates that Fine Uploader is waiting for a response from your server after sending the last chunk of a chunked file. If Fine Uploader is stuck here, then your server is failing to return a response. This seems to be confirmed by your observations of the network request status in dev tools.
Sounds like an issue with your server, or perhaps some sort of browser plug-in. I'm not able to reproduce myself following your steps on IE11. Your next course of action is to look more closely at your server and how it is handling requests in this scenario. If you are seeing any error messages in the developer tools console that suggest Fine Uploader is at fault, please either comment here or open up an issue in the GitHub project's issue tracker.
I am using Spring MVC 3, and JSP/JSTL for the view. I have incorporated reCaptcha in my form. I am noticing some very strange behaviour that is not consistent (i.e. it doesn't happen all the time, it's random) when I submit my form. This ONLY happens with Google Chrome.
I have searched the web but was not able to find any information about this problem.
Basically, when I submit my form including a valid captcha, I am bounced back to the form page YET the captcha was VALID. I got lucky and was able to debug it once and saw the captcha was valid, but the flow of control is somehow being intercepted DESPITE it executing the return ModelAndView logic.
So in other words, it should return a ModelAndView controller with the new view in it, but instead the flow of control goes back to the top of the function!!! and it hits the recaptcha code BUT by this time the recaptcha code is invalid, so it says FALSE. THEN it goes back to the original form page. What is frustrating about this is there is a commit to my production database that happens because the captcha was originally valid and other valid logic that is executed as per normal behaiour.
The reCaptcha box is the only box marked with an error and it states that you must re-enter the code. The only major issue is even if my reCaptcha was bad, it should come back immediately and say try again, which it does, but it SHOULD not appear as valid, highjack the flow of control and then redirect back to the form page.
The end result is I get 2 exact records in the database because the user submits again. It only happens in this way. i.e. I haven't come across a scenario when you have to submit 3 times or more.
This is ONLY happening in google Chrome. I have tried this on firefox and IE but I have never seen this issue. Someone in another country just submitted information via this form and I asked them what browser they were using, and they confirmed it was chrome! I too have had enough encounters with this issue to know it actually is an issue.
Does anyone know why the flow of control goes back to the top of the function?? One other thing I noticed is the flow of control doesn't always go to the bottom, it's like it's got a mind of its own. One other time I was stepping through and it just jumped to the top.
ANY HELP would be kindly appreciated as I am trying to figure this out in a production system!!
Thanks!!
I have a CakePHP site whose homepage is cached for 10 minutes at a time using Cake's default options. However I've been alerted that "every once in a while", once a day or so, it's losing the layout, just displaying the page content without the header, styling etc.
Removing the cached version and regenerating the page apparently fixes the problem. But why would/could this be happening in the first place? I can't say I've seen it happen myself (in any of my CakePHP projects) but does anyone else have any experience of this, or any ideas of ways to fix? Much appreciated!
EDIT: Looking at a broken cached home.php file compared to a working cache file, I've spotted this line:
$controller->layout = $this->layout = 'ajax'; //broken
$controller->layout = $this->layout = 'default'; //working
This seems like a bit of a breakthrough. I guess that sometimes the page is being called by an Ajax request, and then being cached in that format until the cache expires. Anyone know why this might be happening (I don't think we're trying to call the homepage via Ajax anywhere, and we don't even have an ajax layout!) and if there's anything we can do to stop it?
Are you sure no ajax requests are interfering with your code/request?
We had a nightmare issue recently where cake was not rendering the layout on back/forward browser clicks. See here: CakePHP no layout on back and forward button
It may also help to look into the cake request cycle (http://book.cakephp.org/2.0/en/getting-started/a-typical-cakephp-request.html) and narrow down when in the request (and where) the error is occurring, although I dunno how you would reproduce it :)
Hope you figure it out!
Also, if you have any errors in your view, sometimes it won't load the layout. It will just spit out the view until the point where it experienced the error. Perhaps the error is not in displaying your layout, but some odd circumstance where you are generating an error with a Helper.
I've search high and low for an answer to this but unfortunately I'm stuck. The problem is only occuring in Firefox (tested IE, Chrome and Safari also - works fine, no errors of any sort). I'll detail the sequence of events to save posting all my code.
ASP.NET MVC 3 application, basic form loads into a jQuery UI dialog
Custom jQuery to hijax the form submit (serialize the form and then $.post to the server - no compiler errors when debugging and post shows up in Firebug without errors)
Http GET (automatically happens) getting the response object from the server (+ success text and XHR), response is plain HTML in this case (again, shows up in Firebug with no errors)
Custom jQuery to change the HTML of the UI dialog from it's current HTML to the response Html - this is where it fails.
I've used javascript alerts to debug the sequence of events and as soon as the post (and get) is complete, everything just... sort of stops.
As I say, only in firefox! Very odd, just wondering if there's any known bugs with ajax and firefox or anybody has heard of a similar situation?
I must also add, that on other parts of my site, this works perfectly in all browsers! The only difference between this form and the other forms that do successfully complete the function is that the response from this form is the same "page" again but updated rather than a new "page". (I use "page" as I got all this working with Javascript turned off first and for graceful degredation)
HELP! Or laugh, either is fine.
UPDATE
I have tried sending a view with a blank model back as the action result - works in every browser except firefox - firefox retains the values from the previous post! And then I got to thinking - that's a trait of firefox isn't it? And maybe that's why the original "re-direct" html response doesn't work?? I think it's time to give up and let people know they can't use Firefox for that particular function!
Ok so I'm answering my own question.
The only way I found to get round it is to use $.ajax instead of $.post and to use the option async : false
Hope this helps somebody.
Rob
Have you tried adding the attribute [OutputCache(Location = System.Web.UI.OutputCacheLocation.None)] to your Action for your GET? It sounds to me like a caching issue.
I have a problem with ajax updater that i couldnt solve.
I have this code Servicii
It works perfectly in firefox but in internet explorer it does nothing.Also if i open the site from my harddrive it works but it only works for the link once then i have to reload the whole page...
Does anybody have an ideea on how to solve this problem?
Thank you
I've had this exact problem. I'm assuming that you've got a function which periodically makes a request to the server to fetch data then updates the page if that data has changed since the last time you made the request.
Internet Explorer will cache the results of Ajax calls to the same resource even if you tell it not to in your HTTP headers. So if you make a request to get_data?id=whatever over and over again, IE will make the request once and then stop making it in the future and simply return the result of the first request.
The solution is to add a dummy parameter to the request string. So first you request get_data?id=whatever&ie_hack=0 then get_data?id=whatever&ie_hack=1 etc. This will stop IE from caching the results and force it to make the request each time, since it sees a different query string for each request.
I also ran into a problem like this, not with caching but with race conditions. IE executed the render part of the function before the any data was returned. Here's the issue, and solution:
Returned AJAX html breaks IE click events