Current Status

This issue is currently blocked by the following issues:

Please help with those issues to get this issue back on track!

Original Issue Description

I frequently run into this ajax error issue with Drupal. It happens in both Drupal 6 & 7.

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
ReadyState: 4

It's easy to run into. It happens on any browser with or with out extensions. This is because it's the standard way of handling AJAX error in Drupal. If you submit a form, while an AJAX request is processing you receive the error.

To reproduce the error, enable a free tagging text field in a taxonomy which has a couple terms. Get the Ajax going by typing in the first couple letters of popular terms. While the Ajax request is going, submit the form.

This error is in-fact the intended purpose of Drupal and Drupal is throwing this error in Drupal 7 in the misc/drupal.js file via the Drupal.ajax.prototype.error = function (response, uri) in conjunction with Drupal.ajaxError = function (xmlhttp, uri).

In my opinion these alert boxes are a nuisance and something like console.log or watchdog would be a much better place to put these errors. Perhaps a flag should be added to indicate if the error is important or negligible. Since the form is always submitted afterwards, I would consider all these issues negligible. Should a submission with Ajax be required, it's best if perhaps the form waits until it's done or times out, otherwise it should submit it with out the ajax callback and then allow standard form validation to deal with the errors.

My problem with this error is that I mostly make E-Commerce sites with Drupal Commerce or Ubercart. Since these modules make heavy use of Ajax forms, it's very easy to run into this error. For the end user it's very confusing and they'll believe they are doing something wrong and it will scare customers away from purchasing items, thus reducing my conversion rate.


I'd really like to handle it more gracefully. The reason the extended debugging was added is that there are a number of cases where this can happen, and we didn't used to get enough info to figure out what to do. Note that different browsers can present different info.

However, I'd love to catch the "interrupted" case successfully. My +1 to this.

Version:7.x-dev» 8.x-dev

Bumping to 8.x-dev

Testing to see if has this problem as well.

Update: it does not appear to have this issue. According to's misc/drupal.js it's Drupal 6. This is a D7 error, although I do run into something very similar with D6.

Confirmed. I get this issue as well. We have to wait until the autocomplete icon stops spinning every time we add a tag.

@mdupont does bumping it up to D8 mean it's not going to be fixed for D7? I consider this a pretty big UX failure and a huge problem for any user which uses a Drupal 7 site. Especially ones which are Ajax heavy (think Drupal Commerce or Ubercart).

Or does it mean, fix on D8 & backport to D7

Issue tags:+needs backport to D7

@mdupont, no, it's longstanding policy that things have to be fixed in the current development release before they are applied to the current stable release. Tagging this as "needs backport". However... that normally only happens when we actually have a patch.

I'll get this conversation going then. Here's my patch.

diff --git a/htdocs/misc/ajax.js b/htdocs/misc/ajax.js
index 830c8aa..23f4d3b 100644
--- a/htdocs/misc/ajax.js
+++ b/htdocs/misc/ajax.js
@@ -448,7 +448,7 @@ Drupal.ajax.prototype.getEffect = function (response) {
  * Handler for the form redirection error.
Drupal.ajax.prototype.error = function (response, uri) {
-  alert(Drupal.ajaxError(response, uri));
+  //alert(Drupal.ajaxError(response, uri));
   // Remove the progress element.
   if (this.progress.element) {

Is there any valid use case where javascript alerts are used to warn the end user of something going wrong, in language that they'll actually understand? Because if there isn't, I'd rather have it fail silently as to not scare them.

@j0rd you have to attach the patch so it can be tested and applied.

Then set the issue to "Needs review".

You'll want to update the issue summary using the issue summary template too (edit the node).

Assigned:Unassigned» orbiteleven
Category:feature» bug
Status:Active» Needs review
new921 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch autocomplete-1232416-9.patch. See the log in the details link for more information.
[ View ]

Simply commenting out the error alert prevents any notifications when things go REALLY bad. What's happening is that the AJAX request is interrupted by a form submit. It's a recoverable (ignore it) error.

I've attached a patch which will only alert the end user if the response status is something other than 0, meaning uninitialized. It's possible that 1, 2 & 3 should be caught, but those are hard test cases.

Status:Needs review» Needs work

The last submitted patch, autocomplete-1232416-9.patch, failed testing.

new952 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch autocomplete-1232416-11.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-formatted patch?

Status:Needs work» Needs review

Ah, that's my bad. This patch is against D7, where I'm having this problem. Feel I have no idea whether this problem exists in D8, but it happens in D7 and this fixes it.

Frankly, I don't think I'll take time to test this in D8.

@rfay, does moving the status from something to needs review cause the patch to be tested? I was curious about how to do this.

@j0rd yes, putting in CNR makes it get tested. Or if it's been tested already, pressing "retest" puts it in CNR for testing again.

new976 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch autocomplete-1232416-16.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

This patch (against 7.x for now - I'll try to roll 8.x and 7.x patches soon) has a little more conformant coding style.

A lot of my users are complaining about this error popping up when they hit return in certain autocomplete fields, when they click on links on pages that are filtered with views using the autocomplete AJAX filters, and elsewhere. And in investigating this issue and the tens of other issues and forum posts about it, it seems there's absolutely no reason to pop up any error for errors of type 0 anyways... it makes using AJAXified filters and form fields annoying at best.

[Edit: I've also marked #1241482: AJAX autosubmit with exposed filters causes error when user hits return as a duplicate; that issue is solved by this fix].

new985 bytes
PASSED: [[SimpleTest]]: [MySQL] 32,885 pass(es).
[ View ]
new985 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch autocomplete-1232416-17-7x.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here are patches for 7.x and 8.x (the patch in 16 and the patch in 11 actually contained an error - used the wrong JS variable in ajax.js).

These have been tested and are working fine, solving all the problems I mentioned in #16 above. A review and RTBC would be awesome, and thanks for everyone's work on this so far (especially j0rd!) :-)

All I did was complain and raise the issue, which seems to be my largest asset in this community :)

Thanks for the patches @geerlingguy. Looking forward to this getting into core.

Related (this is probably a dup of that one): #634628: AJAX "HTTP Error 0" when AJAX operation is interrupted.. Per the reasoning in #634628-4: AJAX "HTTP Error 0" when AJAX operation is interrupted., this patch is good to go IMO. If you agree that #634628 is a dup, please mark it so.

Also, for those of you interested in this one, I would like to mention #1241984: Disable error reporting to screen during AJAX operations. We should not be having the error reporting as the output of batch api functions...

My only reservation is that we do not completely know what all "status 0" may mean. If it *only* means interrupted, then we're probably OK here.

@rfay - that's all I can find. I've never found another error with status 0. (It seems to be used for 'soft errors' like the one we hit when using autocomplete and dropping the connection).

It seems we could mark #634628: AJAX "HTTP Error 0" when AJAX operation is interrupted. as a duplicate, because most of the issues mentioned there will not be issues anymore if this patch goes through. I have found that Chrome/Safari pop up alerts that stop anything from happening until the alerts are dismissed, while FireFox briefly pops up the alert in some sort of popover, but immediately moves on to the next operation (so it's less disturbing to the user).

It's my best guess that errors of type 0 are meant only for internal use/logging (thus, FireFox doesn't annoy the user with a dialog).

Marked #634628: AJAX "HTTP Error 0" when AJAX operation is interrupted. as a duplicate of this one. Let's make sure the issues described there are in fact fixed...

Version:8.x-dev» 7.x-dev

Sorry if I'm missing the obvious, but I'm very new to Drupal. How do I install the patch?

Sorry if I'm missing the obvious, but I'm very new to Drupal. How do I install the patch?

Version:7.x-dev» 8.x-dev

Please do not change issue metadata. You can apply patches by using the "patch" command-line application or with git (see Documentation page at ).

Version:8.x-dev» 7.x-dev


In linux you do:

cd /your/drupal/directory/public_html
patch -p1 < autocomplete-1232416-17-7x.patch

That should do it. If you're not on linux, you'll have to check on Google about how to apply this patch. `git apply *patch` should work as well.

Version:7.x-dev» 8.x-dev

Please. This has to go in on 8.x before it can go in on 7.x

Can anybody RTBC the patches (or at least the 8.x patch) in #17? Still no problems or any other errors to worry about that I can find...

@rfay sorry, I didn't change it. I think there's a bug in which caused it to be version 7 by default, so when I added my comment it changed. Perhaps it's a browser issue "remember form" issue.

I don't have a D8 version to test on, but I've added this to my D7 version and it appears to work as expected.

While this patch does appear to be working.

I've noticed in the form I have (which has radio options for 30 days, 60 days, 90 days), if I change it from 30 to 90 then submit before AJAX is done, the value submitted is 30. Intended behavior is value submitted to be 90 days.

I've just confirmed, this indeed does happen when the alert is still active, so this appears to be a separate issue. Can anyone point me towards another issue like this in the queue. My searches turn up nothing.

+1 for final porting to D6

D6 doesn't have this problem I believe.

@j0rd - I've seen it, but infrequently. Far fewer parts of Drupal used AJAX as extensively as in D7. It's just less annoying in D6.

@j0rd: the issue marked as duplicate in #28 is a D6 issue.

Status:Needs review» Reviewed & tested by the community

Had this problem and was annoying the shit out of me:P

Thanks @geerlingguy
Also test it in d8 and works as expected.
It is very simple patch and i wonder why it isn't RTBC by now :)

@rootatwc - Wasn't RTBC'ed because we were waiting for someone like you to confirm it; thanks!

Now... we'll see if a core committer will be willing to pull in the code. I'm assigning myself, as I'll try to shepherd this patch through D8 and D7 commits (I'm mostly interested because it's the only core patch I'm still maintaining on one of my sites, and I hate doing that for something so simple).

I'm OK with this. Sure hope we can make more progress with these notifications in general in D8. Putting them in the dblog would be a huge step forward.

Status:Reviewed & tested by the community» Needs work

Oops... No, I'm so sorry. I should have paid much more attention very long ago.

I don't agree with this at all, or at least I'll take some convincing. We added in the extended information *explicitly* for the case of status = 0. And we've gotten lots of information as a result.

It is *not* true that all status=0 messages are harmless. We *do* need to figure out how to separate the harmless ones out.

The extended reporting was added in #646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred") explicitly so we could learn how to handle these. If you search for HTTP Error 0 you'll see two full pages of situations where a status of 0 is not necessarily an interruption.

For this to go forward IMO we have to sort out these situations (an acceptable interruption of an xmlHTTPRequest and a #fail that does the same thing).

Could you move it to dblog for now, and remove it from a user facing interaction. Then in the future figure how how to separate the status = 0 errors from harmless, to not harmless.

You'd still get your debug information and people complaining about finding these errors in their dblog, but you wouldn't mess up the entire user experience for all drupal websites for another couple months while an ideal fix it created.

@j0rd, I think that would be the ticket. I don't know that these notifications are useful in any way to the end user. It's not just the complicated error 0 notifications that should be removed, it's all of them (or maybe there should be some indication at the js level). But essentially we should get this stuff where it belongs, in Drupal's error handling.

I can't apologize enough for not grokking this fully as it proceeded.

See #727278: Add watchdog interface for javascript code to use.

@rfay. Super. Looking forward to these alerts going away for the end user.

PS. No one has mentioned the issue I also raised in comment #32

I've noticed in the form I have (which has radio options for 30 days, 60 days, 90 days), if I change it from 30 to 90 then submit before AJAX is done, the value submitted is 30. Intended behavior is value submitted to be 90 days.

I've just confirmed, this indeed does happen when the alert is still active, so this appears to be a separate issue. Can anyone point me towards another issue like this in the queue. My searches turn up nothing.

While this is another issue, I'd be curious to get feedback from those in this thread (since it's slightly related), before I create a separate issue.

Assigned:geerlingguy» Unassigned

Won't have time right now :-/

Just noticed jDog in one of the Drupal Module feeds on Twitter - that module supposedly routes JS errors through an AJAX call back to watchdog. Might we do something similar here?

Title:Handle "An AJAX HTTP request terminated abnormally" errors more gracefuly.Drupal alerts "An AJAX HTTP request terminated abnormally" when a link is clicked or form is submitted during an AJAX operation
new777 bytes

Here's a module that demonstrates the error that's insensitive to timing. Essentially any time AJAX is applied to the blur event (which is the default ajax event for textfields, as per ajax_pre_render_element()), then clicking a link (or submitting the form) while that element has focus, results in an alert message, because AJAX is immediately started (due to the blur), and then aborted by the browser in processing the link click / form submission.

According to, one of the statuses that the complete() callback can receive is 'abort', and ajax.options.complete() within Drupal.ajax() only invokes the error handling logic for a status of 'error' and 'parseerror', so if somehow a browser interruption of ajax could be made to send 'abort' instead of 'error', we'd be all good. But I don't know how to do that. It looks to be deep in the internals of jQuery and/or browser implementations.

I'm retitling this bug to deal with this specific issue of handling aborts better. Earlier comments link to other issues for removing alerts entirely from error handling, which might be the only way to deal with this, unless some JS guru can figure out how to distinguish aborts from errors.

I don't think there is a way to make #46 happen. The problem is that abort is not called. Here the request is terminated by the browser because it's going to another page and when he does that, abort is not called, it's just terminated.

To make #46 happen you'd need to have a registry of all ajax calls (and Drupal.ajax is not it, for form jquery.form takes care of form submit and it doesn't use Drupal.ajax) and go through it calling abort() on each of them on the window.unload event. It's just backward and wrong, we all know registry is such a good idea (I'm talking about windows, not a troll about the Drupal one please)…

What needs to be done is make error handling less obnoxious. There is a setting to display php errors, there needs to be one for JS errors as well as using console.log() by default where available.

For testing purpose, adding a sleep(5) in the code above helps if your webserver is faaast.

new2.1 KB
FAILED: [[SimpleTest]]: [MySQL] 33,345 pass(es), 2 fail(s), and 3 exception(es).
[ View ]

What needs to be done is make error handling less obnoxious. There is a setting to display php errors, there needs to be one for JS errors.

I agree. Is there a need for it to be a different setting, or can it reuse the same one? Here's a patch that uses the same one. One argument for creating a different setting though is that while screen reporting of PHP errors can be disabled and the errors still be viewable in dblog/syslog, that is not the case with JS errors, without using console.log(), solving #727278: Add watchdog interface for javascript code to use, and/or something else.

Status:Needs work» Needs review

I don't think there is a way to make #46 happen. The problem is that abort is not called. Here the request is terminated by the browser because it's going to another page and when he does that, abort is not called, it's just terminated.

Conceptually, it seems to me that there ought to be some way to bind to some event that runs before the browser aborts the xhr object, and to call jQuery's abort() on it ourselves. However, I haven't found which event this can be done with successfully.

To make #46 happen you'd need to have a registry of all ajax calls

This, I'm confident is solvable in a nice enough way (without all the problems of Windows registries). It's which event to bind to that's where I'm currently stuck.

Note that this comment doesn't imply I'm against #48. Something along those lines is also worth doing. But in addition to that, I think we should be better about distinguishing real errors from not real ones.

Status:Needs review» Needs work

The last submitted patch, ajax-error-display.patch, failed testing.

Linking to meta #1419652: [Meta] javascript logging and error reporting.

My issue with the registry is not that it can be hard to do, it's that it's not js-like. You'd have to bind the unload event to each request when they are created, not going through each of them, events are exactly what should be used to do this kind of things and the browser ought to be fster than a loop dealing with this.

Here is an issue for a logger that uses error_level #1419648: javascript error reporting interface.

Http error 0 is returned also when a destination server does not accept connections so that no connection was established to begin with. This is probably the error which should be reported to the user (same as browser reports when a page cannot be loaded).

Status:Needs work» Postponed

Can't do anything about this issue without #1419652: [Meta] javascript logging and error reporting

We've just come across this, and a closely related issue to this (The alert is actually being triggered in misc/autocomplete.js). This is an easy issue for site end-users to come across. They are not going to report bugs to - they're going to leave the site they're on and try one that's less buggy which is bad news for site owners.

While I appreciate the need to capture debug information, I can't see the justification for allowing such an intrusive way of doing so into a public, stable release - we're putting the needs of the developers ahead of the needs of the end-user.

Has this alerting served its purpose? Have we captured the information required to fix the status 0 bug? If so, can we please just take out the obtrusive alerting from 7.x while we fix the real issue (Maybe leave the debugging in the dev releases even
alpha/beta releases for 8.x?). While this stays in the stable releases we'll have to patch core (As per comment #7, and an equivalent in autocomplete.js) for every 7.x based site we release, and re-patch it every time it's upgraded as it's unacceptable for us to deploy sites with this behaviour in place.

I understand your issue but that's the way it ended up and the shortest path to get this fixed is to agree on a way to deal with this. Feel free to contribute to the meta issue to help get this moving forward, there is more to it that just this obnoxious alert :)

Should the patch in #11 be enough to fix this? It's helped me, but I think I need to do something more.

I have a Batch API process that's often fails to complete, it terminates with the error in the original post.

I've applied the patch. This appeared to have worked as it's stopped the error occurring when a form is submitted. However I'm still getting the error.

The system is quite busy at the time with users modifying content, themers doing 'drush cc all' and more. I'm guessing some actions they're doing are triggering this.

Does anybody know what could be causing this (even though the patch in #11 is applied) ?

Title:Drupal alerts "An AJAX HTTP request terminated abnormally" when a link is clicked or form is submitted during an AJAX operationDrupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors
Priority:Normal» Major
Status:Postponed» Active

Reactivating this as a major bug, since I agree with #55 that bogus alerts interrupting regular site visitors / editors is bad. My recommendation for the next step here is to merge the Drupal.log() function from #1419648: javascript error reporting interface, and change our AJAX alerts to use it. That issue in the abstract isn't attracting much attention, but as part of an attempt to fix a major bug, hopefully will.

Status:Active» Needs review
new3.95 KB
FAILED: [[SimpleTest]]: [MySQL] 35,105 pass(es), 2 fail(s), and 3 exception(s).
[ View ]

Ok reworked a bit the patch in the other thread, here it is. I don't really like how the code looks but it works. feel free to take it apart to make it better :)

It adds:

Drupal.log(message, 'status');  console.log(message);
Drupal.log(message, 'warning'); console.warn(message);
Drupal.log(message, 'error');   console.error(message);
Drupal.log(message, 'myType');  console.log('myType', message);

In the context of this issue, this patch replace the alert calls to Drupal.log, getting rid of the initial issue.

Status:Needs review» Needs work

The last submitted patch, core-js-drupal-log-1232416-59.patch, failed testing.

Status:Needs work» Needs review
new4.87 KB
PASSED: [[SimpleTest]]: [MySQL] 35,138 pass(es).
[ View ]

testbot should be happy now.

new4.81 KB
PASSED: [[SimpleTest]]: [MySQL] 35,142 pass(es).
[ View ]

Thanks for the patch. As-is, this wouldn't leave us much better off as it potentially still leaves in the alert() for browsers that don't support console.log() [Approx 70% of our end-users unfortunately], so it's still something we couldn't deploy into production.

I'd prefer to see the fallback be to do nothing as per the attached revised patch.

Would that be considered?

Yeah I wasn't sure. I guess we need two settings for error logs after all. That way you could disable JS log so that alert won't be used. But if you have IE6 and wants to debug something in it just ignoring what Drupal.log display is not very helpful.

If someone is really doing some diagnosis on this I don't think asking them to change the code to alert() is a significant effort.

It certainly nowhere near outweighs the benefits of chucking debug messages in front of unsuspecting site visitors who are just trying to browse a website [IMHO].

There are solutions that implement a console.log equivalent cross platform (E.g. but I don't think that should be in core either - seems much too heavyweight, and I've yet to see anything that suggest the information we're capturing is useful in identifying the issues anyway?

Remember that this bug is about random debug messages confusing site visitors/editors. For me, the patch at #62 achieves this.

@leewillis77 just tried #62 on a D7 site. I'm far from a JS expert, so apologies if I'm missing something obvious :)

  1. I start a Views AJAX request.
  2. I click on a link to another page before the AJAX request is finished (this is what previously caused the annoying alert).
  3. In Chrome, if I have Pause on uncaught exceptions enabled from the developer tools, then it stops on the line
    console[mapToConsole[type]].apply(this, args);
    with a TypeError exception.

It seems to me that the first argument to apply() should be console, and that seems to stop the exception (but as I say I'm no JS expert).

console[mapToConsole[type]].apply(console, args);

Thanks for the patch, we couldn't go live with those alerts appearing!

new4.87 KB
PASSED: [[SimpleTest]]: [MySQL] 35,638 pass(es).
[ View ]

fixed, I rerolled #61 since I don't know if alert should be removed just now. Worst case, it's possible to remove it in a follow up issue. Disabling error display could work too.


@aiquandol, we don't have to do the "subscribing" thing, which on this issue sent an email to 26 people. There's now a "Follow" button in the upper right of any issue, which lets you subscribe without sending out all those emails. It's a great change, just in the last few months, on

Thank rfay! I didn't notice :)

Tried patch #61 and #66 on a D7.12 site but couldn't get them to work, still keep getting annoying Javascript error dialogs.

As a (dirty) quick fix, I patched misc/drupal.js to get rid of the error dialogs.
Hope this helps anyone who needs to fix this quickly, even if it's dirty.

diff --git a/misc/drupal.js b/misc/drupal.js
index 83b0884..2ff06ba 100644
--- a/misc/drupal.js
+++ b/misc/drupal.js
@@ -363,6 +363,10 @@ Drupal.ajaxError = function (xmlhttp, uri) {
   readyStateText = xmlhttp.status == 0 ? ("\n" + Drupal.t("ReadyState: !readyState", {'!readyState': xmlhttp.readyState})) : "";
   message = statusCode + pathText + statusText + responseText + readyStateText;
+  // Prevent error dialogs from showing.
+  throw new Error(message);
   return message;

see #7 for a more aggresive solution :p, also this patch is for D8. D8 and D7 javascript are starting to diverge quite a bit so that's unlikely to apply easily.

Reroll and remove the alert fallback like suggested in #64. If there is no console in the browser, it just silently ignore the call.

throwing an error might not be a bad idea either. I don't have an opinion on that yet.

new4.74 KB
PASSED: [[SimpleTest]]: [MySQL] 36,343 pass(es).
[ View ]

ok, with the patch now :p


I've applied the patch in D7 (using patch -p2) and it felicitously keeps the otherwise-jarring Ajax error alerts away from regular users.

This has been a serious problem -- users are always deeply perplexed when they get such alerts.

Status:Needs review» Needs work

nod_: Looks good to me, only thing is the TODO. But i think it's a good idea to log the error, way better than alert.

+++ b/core/misc/drupal.jsundefined
@@ -111,6 +111,52 @@ Drupal.detachBehaviors = function (context, settings, trigger) {
+ * TODO description

Still a @TODO?

Discussed this in IRC with nod_ and this needs a separate setting

i had a closer look, i think it would be better to extend admin/config/development/logging with additional options for javascript logging, i never use 'all messages' while building a site, so it would mean i'm missing the js errors :/

+++ b/core/misc/ajax.jsundefined
@@ -448,7 +448,7 @@ Drupal.ajax.prototype.getEffect = function (response) {
Drupal.ajax.prototype.error = function (response, uri) {
-  alert(Drupal.ajaxError(response, uri));
+  Drupal.log(Drupal.ajaxError(response, uri), 'error');
   // Remove the progress element.
   if (this.progress.element) {

Could we also expose Drupal.log as an ajax.command? :-)

+++ b/core/misc/drupal.jsundefined
@@ -111,6 +111,52 @@ Drupal.detachBehaviors = function (context, settings, trigger) {
+ * TODO description
+ *
+ * Drupal.log(message, 'status');  console.log(message);
+ * Drupal.log(message, 'warning'); console.warn(message);
+ * Drupal.log(message, 'error');   console.error(message);
+ *
+ * Drupal.log(message, 'myType');  console.log('myType', message);

alert() functions are so gross. Glad they're going away. Probably want some docs here though.

+++ b/core/misc/drupal.jsundefined
@@ -111,6 +111,52 @@ Drupal.detachBehaviors = function (context, settings, trigger) {
+Drupal.log = (function () {
+  // Initialisation is done in a closure in case Drupal.log is used in a
+  // demanding loop, inside an onresize function for example.
+  // Status from drupal_set_message().
+  var status = ['status', 'warning', 'error'];

We should probably use Drupal.log() in the doc block of Drupal.ajax too.

-12 days to next Drupal core point release.

We have drupal commerce installed and this is currently my #1 issue.
Will the patch be committed to the next drupal 7 core release? Or do I have to apply the patch?

-12 6 days to next Drupal core point release.

@urlaub not like it is now, we need proper settings and some more documentation first, than some testing.

@attiks thank you for the reply!
Regarding our user case with drupal commerce, it would be even better not just to hide the Ajax Error but deactivate the Ajax send button (add to cart in commerce) until everything is loaded in order to avoid the Ajax Error. Unfortunately many visitors just ignore the "Please wait" message - I see many "Invalid form POST data." log messages.

Tried #70. That worked for me... Thanx Rade....
But I dont have any other opinion on that..... :)


Status:Needs work» Needs review
new7.17 KB
PASSED: [[SimpleTest]]: [MySQL] 36,591 pass(es).
[ View ]

Ok better patch.

I moved Drupal.ajaxError into ajax.js it make more sense. I also changed the way it's constructed. the method now returns an object with a toString method (that'll work during concatenation) that is doing the user-friendly processing only when it needs to be serialized (in core only progress bar uses that).

New patch is directly using console.{log,warn,error} instead of having an awkward wrapper. The only thing it's doing is creating a console object with the 3 methods to avoid crashing in older browsers.

If someone is using firebug lite of another js tool overriding the console object, it should be included before drupal.js is there is any problem with initialization.

I removed the error logging level altogether since we really don't want stray console.log anywhere in the code and that makes things much simpler.

Status:Needs review» Needs work

+++ b/core/misc/ajax.jsundefined
@@ -71,6 +71,55 @@ Drupal.behaviors.AJAX = {
+        statusCode = "\n" + Drupal.t("An AJAX HTTP error occurred.") +  "\n" + Drupal.t("HTTP Result Code: !status", {'!status': xmlhttp.status});

one space to many after second +

+++ b/core/misc/drupal.jsundefined
@@ -5,7 +5,7 @@ jQuery.noConflict();
+(function ($, Drupal, window, document, console, undefined) {

Is there a reason why you pass console as a separate variable? Why don't you use window['console'] in here?

Status:Needs work» Needs review
new7.17 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch core-js-drupal-log-1232416-85.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

reroll for the space.

I'm just planning ahead. I'd like to avoid having to access window from anywhere inside the file-closures, it'll make things easier later on.

Status:Needs review» Needs work

The last submitted patch, core-js-drupal-log-1232416-85.patch, failed testing.

Status:Needs work» Needs review

That's some scary whitespace :D

#85: core-js-drupal-log-1232416-85.patch queued for re-testing.

So much code in this post, some patches not having passed their tests... is there a definite solution to this problem?
The patch listed in #16 comes from Sep 22, 2011 - how come it has not been adopted into the core in 7.14 release of May 2012...

You're right a lot of things have changed in this issue over time.

Patch in #85 is the one to look at.

patch in #16 was not the right way to address this problem.

Status:Needs review» Needs work

Actually I think a better way to do that is throw an error like suggested in #70, helps get rid of all the console code. and throwing an error should have a stack trace with it too.

Status:Needs work» Postponed

Drupal.ajax needs to be cleaned up before properly fixing this issue. So #1533366: Simplify and optimize Drupal.ajax() instantiation and implementation should be fixed before #1606362: Use throw when an ajax error occurs and extend JavaScript's Error object and this one finally.

In the meantime the patch in #85 will work.

Subscribing. This is an annoying issue, that I ran into during autocompletion. I managed to fix it however, by adding a global .js (for example, in the theme), and adding the following:

(function ($) {
$(document).ready(function() {
    beforeSend: function(jqXHR, settings) {
      settings.error = function(jqXHR, textStatus, errorThrown) {console.log('ajax error: ' + textStatus);};

This overwrites the error handler, but only in case that the beforeSend hook was not overruled when creating the AJAX request. This will work in most cases.

Status:Postponed» Needs review

#85: core-js-drupal-log-1232416-85.patch queued for re-testing.

Status:Needs review» Postponed

re #93: This is a good stopgap for those who need it now; though beware that the console object is not standard. In particular, IE will fail hard because the console doesn't exist unless developer tools are on. See this stackoverflow thread for workarounds.

+// Create dummy functions if browser console is not available.
+if (typeof console !== 'object') {
+  console = {
+    log: function () {},
+    warn: function () {},
+    error: function () {}
+  };

Not too sure about this, we're essentially not testing what we need to test. If something were to define a console object without those methods, it would error out and we'd never catch it.

Ben Alman has a nice little wrapper script for this (, which pretty much boils down to
if (window.console && console.log) { console.log(foo); }

so in our use-case, I think it would be better to use something like

window.console = window.console || {};
window.console.log = window.console.log || function() {};
window.console.warn = window.console.warn || function() {};
window.console.error = window.console.error || function() {};

or even

window.console = window.console || {};
var methods = ['log', 'warn', 'error'];
for (var i = 0; i < methods.length; i++) {
  window.console[methods[i]] = window.console[methods[i]] || function() {};

That way, you would still catch console objects that exist, but aren't what you expect. (naturally, if a console object with a log method is defined, but it doesn't act like we assume, it'll still fall trough)

Also, I agree with #70 that we should throw a proper error instead of alerting.

Once we have things throwing proper errors, we can look into how we want to handle/display them.

#93 sounds good to me, but because of the possible IE freak-out on console log , I altered it a little bit. I also put it in Drupal.behaviors...

You can use this in your theme script:

Drupal.behaviors.YourThemeNameOrWhatever = (function(){
return {
attach:function(context, settings){
beforeSend: function(jqXHR, settings) {
  settings.error = function(jqXHR, textStatus, errorThrown) {
//do nothing... end user doesn't need to see debugging info, uncomment console log code to debug
//{console.log('ajax error: ' + textStatus);};

Note that this completely disables the reporting of the error, which will make debugging impossible.

I'm not offering this as a final solution, this should just work to fix the end user problem while this task remains postponed until the Ajax error reporting gets addressed. (see #55, i whole-heartedly agree with that post..)

In the mean time, I'll wait for the order of events described in #92

The code above will work if you have a js file you can drop it into, otherwise, if you want to patch up the core with a temporary fix, see #85

Personally, I don't want to patch core with a temporary fix that doesn't seem to have any future part in the next release...

if you only want to disable the error reporting, you can just asplode the window.alert function altogether. I've done this in a few production sites where a third party script we had no control over would use window.alert in some occasions. No module or component should ever rely on this anyway.

window.alert = function() {};

this can be in any script and can be executed at any time during the page build

I've also done another thing once, which is relaying everything piped into window.alert to watchdog, but that requires you to set up a page to catch the ajax calls, clean them and log it in watchdog.

new6.65 KB
PASSED: [[SimpleTest]]: [MySQL] 39,272 pass(es).
[ View ]

Attaching #85 re-rolled against 7.x and/or 7.14. Might be useful for someone.

Status:Needs work» Needs review
Issue tags:-needs backport to D7

Status:Postponed» Needs work

The last submitted patch, core-js-drupal-log-1232416-100-D7.patch, failed testing.

Version:8.x-dev» 7.x-dev
Issue tags:+needs backport to D7

Lets test last patch....

Version:7.x-dev» 8.x-dev
Status:Needs review» Postponed

That's a postponed 8.x issue, please get the other issues it depends on moving along first.

The patch was provided for convenience, not as a patch to be reviewed.

My plan was to revert issue status back to D8, postponed when test finishes. I run test just to help people decide it is a good patch.


Issue summary:View changes

Updated issue summary.

Status:Postponed» Needs review

Status:Needs review» Postponed

Issue summary:View changes

Removed postponed text.

Okay; I updated the issue summary to mention those two issues. This issue could probably do with a good issue summary, too.

new6.65 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch core-js-drupal-log-1232416-110.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-rolled ##10 to apply to 7.15, as we're experiencing an ajax error on a site (without any real time to track down the root cause of an "Cannot read property 'field' of undefined" error), and find the console much less intrusive than an alert box every time somebody wants to add another value to a field while editing a node.

My workaround for drupal 7 with custom theme/module js (slightly modified version of #98). My motivation is to show the errors, if there are any (although they won't look nice in alert box) but do not show the warnings if AJAX HTTP request terminated abnormally:

(function ($) {
  Drupal.behaviors.YourModuleNameOrWhatever = {
    attach: function(context) {
      // JavaScript Alert bei AJAX-Autocomplete deaktivieren. Siehe:
      // Drupal alerts "An AJAX HTTP request terminated abnormally" during
      // normal site operation, confusing site visitors/editors:
      // (#98)
        beforeSend: function(jqXHR, settings) {
          settings.error = function(jqXHR, textStatus, errorThrown) {
            if (jqXHR.status) {
              // An AJAX HTTP error occurred.
              // Show error Message.
              alert(Drupal.ajaxError(jqXHR, settings.url));
            // do nothing if AJAX HTTP request terminated abnormally.

Status:Postponed» Needs review

#85: core-js-drupal-log-1232416-85.patch queued for re-testing.

Status:Needs work» Needs review


I might be being thick but I'm getting the below when patching #85:

patch -p1 < core-js-drupal-log-1232416-85.patch
patching file core/misc/ajax.js
Hunk #1 FAILED at 71.
Hunk #2 FAILED at 252.
Hunk #3 FAILED at 441.
3 out of 3 hunks FAILED -- saving rejects to file core/misc/ajax.js.rej
patching file core/misc/autocomplete.js
Hunk #1 FAILED at 312.
1 out of 1 hunk FAILED -- saving rejects to file core/misc/autocomplete.js.rej
patching file core/misc/drupal.js
Hunk #1 FAILED at 5.
Hunk #2 FAILED at 112.
Hunk #3 FAILED at 338.
Hunk #4 FAILED at 407.
4 out of 4 hunks FAILED -- saving rejects to file core/misc/drupal.js.rej
patching file core/misc/progress.js
Hunk #1 FAILED at 87.
1 out of 1 hunk FAILED -- saving rejects to file core/misc/progress.js.rej

I get this on #100:
patching file misc/ajax.js
Hunk #3 FAILED at 497.
1 out of 3 hunks FAILED -- saving rejects to file misc/ajax.js.rej
patching file misc/autocomplete.js
Hunk #1 FAILED at 304.
1 out of 1 hunk FAILED -- saving rejects to file misc/autocomplete.js.rej
patching file misc/drupal.js
patching file misc/progress.js

Status:Needs review» Needs work

The last submitted patch, core-js-drupal-log-1232416-110.patch, failed testing.

Status:Needs review» Needs work

#111 works for me. Thanks!

Thanks to @j0rd for creating this issue. I had urgent need for solving this, the error suddenly occurred out of the blue the same day I went live with a site I've been working on for 9 months. My "bug" is triggered in an exposed filters view form where a lot of js comes in to reshape the layout to colmnize the checkboxes and make headings of the group labels that let you "select/unselect all in group" by clicking label. So it is not an autocomplete ajax event that was cut short, as far as I can judge.

I did a quick and dirty fix by altering row 451 of misc/ajax.js (Drupal 7.15) to "console.log" instead of "alert".

Will this message be moved to be set as console.log instead of alert in Drupal 7? Or is all work on this targeted at Drupal 8?

I really hate to hack core, however tiny the hack -- it messes up a nice core upgrade workflow.

@#116: you could just overwrite window.alert with a conditional console.log (conditional so it won't bug out on IE), instead of hacking core's ajax.js:

window.alert = function(arg) { if (window.console && console.log) { console.log(arg);}};

@seutje That sounds even better. But how do I do it? Should I put the line of code you suggested in my themes .js ? I always have a themename.js file for my themes with this structure

(function ($) {
      window.alert = function(arg) { if (window.console && console.log) { console.log(arg);}};
   }); // END document ready

Should it be in document ready like above or outside the entire structure like this:

window.alert = function(arg) { if (window.console && console.log) { console.log(arg);}};
(function ($) {
   }); // END document ready

It seems like a general instruction so I'm guessing the second alternative

Yes, you don't need jQuery and you don't need to wait until the DOM is ready afaik. (so yea, the second)

to keep this issue from getting sidetracked even more, I figured I'd reroll the last patch, which was a pain in the ass. After I was done with it, I realized why: it was a D7 patch (doh >_<), so I'm not even gonna post it...

No user bumping to 8.x this needs fixing on 7.x users should NEVER see this kind of rubbish/.....

I agree that a fix on 7.x would be most welcome indeed.

I fixed this with console.log as mentioned in #116, because the error doesn't occur on IE in my case. I got the feeling that the script recommended in #117 would kill all alerts, which is perhaps not always desired behaviour (there could be simple form validations etc that should still alert).

Status:Needs work» Postponed

Ok guys, I get that it's a painful issue but there is something that can be done just help me out, I don't have enough time to do everything.

See #108 for the TODOs.
See #85 for a D8 patch.

Back to postponed, please don't litter the issue with wildly different D7 patches. Thank you.

Getting this during various processes, including checking for module updates. I'd say this is a pretty serious issue since it prevents necessary processes from completing. If the checking of module updates stalls and I hit the browser's stop or reload button, the AJAX error is displayed, so clearly there's not double-check if some timeout or temporary drop in connection occurs.

Anyone having lots of AJAX issues might want to try disabling the jquery_update module, worked for me. Just spreading the info, unsure if it's related to this issue.

@nod_ , I don't mean to derail this with any more D7 related code but I wanted to post a combination of #93 (@bvanmeurs), #97 (@seutje) & #98 (@tmsimont). I made a few adjustments to the Drupal.behaviors syntax and dropped this code into a js file (js_injector) temporarily resolving this issue without the need of a core patch.
I appreciate all the hard work everyone is putting in on this.
I'm using an autocomplete path callback to an LDAP api query from a CCK text field. LDAP can generate a lot of ajax feedback on parse errors and interrupted queries. The users didn't need to see any of that.

* Drupal.behaviors.ajaxHijackErrors
* HiJack the ajax error reporting in D7. Avoiding the alert box for users
* - comments: #93, #97, #98
Drupal.behaviors.ajaxHijackErrors = {
  attach:function(context, settings){
    if (typeof context !== 'undefined') { //run only if there is a context var
      window.console = window.console || {};
      var methods = ['log', 'warn', 'error'];
      for (var i = 0; i < methods.length; i++) {
        window.console[methods[i]] = window.console[methods[i]] || function() {};
      } //end for
        beforeSend: function(jqXHR, settings) {
          settings.error = function(jqXHR, textStatus, errorThrown) {
            //end user doesn't need to see debugging info
            {console.log('ajax error: ' + textStatus);};
          }; //end settings.error
        } //end beforeSend
      }); //end $.ajaxSetup
    } // end if (typeof context !== 'undefined')
  } // end attach:function(context, settings)
} //end Drupal.behaviors.ajaxHijackErrors

new20.15 KB

I get this same AJAX HTTP error message when I expose an HTML5 audio player in a Drupal 7 View. It also causes the View to freeze, and the whole system to slow down. But I expose a Flash audio player in the same View, there is no such problem. For the error message that I receive, see the attached png file.

I have the issue with a live drupal 7.19 site which is putting off a lot of my users (particularly users on Safari 5 versions up to 5.0.6). Which patch should I use as there appears to be no clear consensus on the fix? The issue appears to occur when a user has used an 'autocomplete' field linked to a taxonomy and saves to quickly after using this field i.e. the AJAX is probably still running when the user saves.

@bentleychan that sounds like an error with your HTML5 audio player not the drupal core. The error you're seeing is pretty generic. You should post an issue with the HTML5 audio player module.

@spessex my code in #98 works for me. you could try the code in #125, too. These codes just basically disable the error. Drop them in your theme script file and make sure you've got that script loading into your site. You could also drop that into a module or something. Either chunk of JS could be placed anywhere

Issue tags:-needs backport to D7
new1.77 KB

For those looking for a solution for Drupal 7, this might help. Just add it to your theme javascript and it should send all errors to console.

Version:8.x-dev» 7.x-dev
Status:Postponed» Needs review
new941 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch abort-xhr-1232416-130.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

patch misc/autocomplete.js to allow abort

Version:7.x-dev» 8.x-dev
Status:Needs review» Postponed

See #122.

Status:Needs work» Needs review
Issue tags:-Needs issue summary update

Status:Postponed» Needs work

The last submitted patch, abort-xhr-1232416-130.patch, failed testing.

Status:Needs review» Postponed
Issue tags:+Needs issue summary update

If it's something it's Need work, not need review. See #122.

Ok guys, I get that it's a painful issue but there is something that can be done just help me out, I don't have enough time to do everything.

See #108 for the TODOs.
See #85 for a D8 patch.

The solution in #129 is not working for me

Any Idea to resolve this issue on dr7?

try the one in #125

I tried the following:

window.alert = function() {};

And I was able to delete that annoying warning.

sorry, what line?

Issue tags:+needs backport to D7

Also experiencing this problem on a D7 site, and also in need of a fix, so re-tagging.

Was experiencing this issue on a D7 site; neither #125 nor #129 worked in this case. The D7 patch in #17 did work.

The D7 patch in #17 did work for me too.

I manually apply the patch. folder misc/ajax.js
find alert(Drupal.ajaxError(response, uri)); and replace with:

  if (response.status != 0) {
    alert(Drupal.ajaxError(response, uri));
} folder misc/autocomplete.js
find alert(Drupal.ajaxError(xmlhttp, db.uri)); and replace with:

  if (xmlhttp.status != 0) {
   alert(Drupal.ajaxError(xmlhttp, db.uri));

Instructions to aply a patck manually (saves you from a lot of work):

The D7 patch in #17 did work for me too on drupal 7.23.

re #129, there is a fault in this file, where in normal operation Drupal.ajax may not exist, so line 5 needs to be added
if(typeof Drupal.ajax != 'undefined'){

and line 56 to be
}};//end if typeof Drupal.ajax

otherwise the file results in the site error:
Uncaught TypeError: Cannot read property 'prototype' of undefined in ajaxfix.js

and weird things happen, like IMCE buttons refuse to load.

Issue summary:View changes

Added new blocking issues.

Status:Postponed» Needs review

#16: autocomplete-1232416-16.patch queued for re-testing.

I am using Commerce Cart Ajax module but when I am creating a new block and did use ajax : yes , drupal is throwing error "
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /commerce_kickstart/admin/structure/views/ajax/preview/shopping_cart/block/4
StatusText: OK
Tekege Store
@import url("http://localhost/commerce_kickstart/modules/system/system.base.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/modules/system/system.menus.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/modules/system/system.messages.css?m...");
@import url("http://localhost/commerce_kickstart/modules/system/system.theme.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/modules/system/system.admin.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/modules/contextual/contextual.css?mt...");
@import url("http://localhost/commerce_kickstart/modules/comment/comment.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/modules/node/node.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/sites/all/modules/om_maximenu/css/om...");
@import url("http://localhost/commerce_kickstart/modules/user/user.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/librarie...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/modules/toolbar/toolbar.css?mt9cb2");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/modules/...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/themes/s...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/themes/s...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/themes/s...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/themes/s...");
@import url("http://localhost/commerce_kickstart/profiles/commerce_kickstart/themes/c...");
Skip to main content
Hello Astha
Log out
Administrative toolbarProductsActionsManage products
Add a product
Variation types
OrdersActionsManage orders
Add an order
ContentActionsManage content
Manage comments
Add content
SettingsContent types
Store settingsAdvanced store settingsCustomer profiles
Payment methods
Checkout settings
Currency settings
Line item types
Order settings
Pricing rules
Commerce Search API
Product settingsCategories
Variation types
Site settingsVisual & LayoutAppearance
Advanced settingsStructure
Site reports
Home Administration Site settings Visual & Layout Views
Status message
Line item removed.
TitleEdit Title
shopping cart
ContentFilter criteria
Edit Commerce Line Item: Line item is of a product line item type
Add new
Edit Commerce Line item: Display path
Edit Commerce Line Item: Title
Edit Commerce Line Item: Line item ID
Edit Commerce Line item: Product
Edit Commerce Line Item: Delete button
Edit Global: Custom text
Add new
Sort criteria
Add new
Contextual filters
Edit Commerce Order: Order ID
Add new
Edit Commerce Order: Line items
Add new
Total: 0.00 INR
Edit view
Configure block
Configure block
Proudly built by Commerce Guys
Configure block
Powered by Drupal Commerce "
Kindly post any relevant information asap.

Hi achauhan, this is unrelated to this particular issue (I.e. error while installing Drupal). It could be a similar issue though, where php timeout is being exceeded.

I can confirm, that #17 works on a Drupal 7.22
It was very important for us, thank you for the patch!

Status:Needs review» Postponed

Issue summary:View changes

update dependant issue list

Issue summary:View changes
Status:Postponed» Active

Unpostponing, it is possible to at least allow contrib to override the alert() functionality without many changes:

a) Define error codes (constants) for the error conditions (e.g. 1 = normal ajax error, 2= aborted, 3 = ...) based on the extra information we have.
b) Have Drupal.ajaxError return a "code" and a message
c) Instead of alerting, use Drupal.showAjaxError() therefore eliminating the hard coded alert.
d) Make it possible to override Drupal.showAjaxError(errorCode, message) - as its JS thats automatically true.
e) In contrib code use the errorCode to determine to show the message via alert() or console.log() or ...

This does not solve the issue, but it makes it easier for contrib to do something about it.

And this without hindering further progress, where the JS errors could be shown within showAjaxError() to the new JS messages area.

( I come from the Drupal 7 view here. )

As noted in #141:
Patch in #14 works on 7.23, the two javascript solutions (#125 #129) seemingly not (at least not out of the box – I applied the script changes proposed in #144).

I too have bad experiences with the UX – the wording itself made users think, they've run into inrecoverable errors, closing form pages and contacting us. This happened on several projects.

If this issue doesn't move forward – could we maybe extract the little script override in a custom module? I feel it's a bit cumbersome to patch core on every update and seems more robust than copying code in my template files.

The problem still exists and I can also tell, that "simple" users are frightened by this message. So what can we do to at least have a simple way to fix it, until this is finally fixed?

The situation is not acceptable for production sites, I think.

17: autocomplete-1232416-17-7x.patch queued for re-testing.

The last submitted patch, 17: autocomplete-1232416-17-7x.patch, failed testing.

I can also confirm that #17 works great for D7. I furthermore think, that this is the right way to handle the special status code of "0"!

Here is #17 again for the current version of Drupal 7.

...and lets make sure people use the latest patch available ;)

#156 works perfectly for 7.24

#156 works GREAT!. Finally fixed a long standing problem. When I used xposed filters (views) with auto submit, and had a text field, pressing enter would reset the filter and do nothing. Now it actually works. Text field input with autosumbit and pressing return works. LOVE IT.

Thanks for the great work!

Due to the feedback, is it perhaps possible to get this into the 7.26 release?

It appears to me that all this does is stop an error message appearing, which although it is extremely annoying, in some (most?) cases is better than just pretending there is nothing wrong at all.

Let me first say that I am as unhappy as anybody about this error; it has caused me hours of grief, simply because I could not (I thought) update a path for a views display. I have even spent a considerable amount of time upgrading from 7.14 to 7.25 in order to try and get rid of it. When the problem was still there on 7.25, I manually patched it with the proposed fix above.

The proposed fix does indeed stop the error message appearing. However, since it doesn't do anything about the underlying problem, it arguably makes things more confusing not less.

In my case, before the fix, when I click on the view display path, I get the Ajax error message, and I cannot rename the path. After the fix, when I click on the view display path, nothing happens. I'm not sure if I clicked, so I click again. And again. Nothing happens each time. I have no idea what is going on. At least in the case of the annoying pop-up message I am made aware that there is some sort of error preventing me from doing what I want. (In fact, for this case of renaming the path, I found a workaround of right-click and open link in new tab.)

My experience, following on from my post #161, is that I am now removing the patch, because I prefer to see the errors rather than see nothing happening when there is an error.

Sorry, but I still think this is unacceptable for end-users. They are just frightened and don't know what the hell happened. I agree, that it's good to track errors, but not for normal users!

So either:
Only display these errors only for admins (permission)
OR Log them anyway or just put them out to javascript console
OR provide a setting to let the admin decide

But the current status is unacceptable for end users!

One possible solution would be to replace the horrible "alert()" by a console.error() (see: )

For example:

//Instead of:
alert("An error occurred while attempting to process " + ajax.options.url + ": " + e.message);
// use
if (typeof console != "undefined") {
  console.error("An error occurred while attempting to process " + ajax.options.url + ": " + e.message);

I finally decided to write a module to prevent alerts completely due to the described end user problems with this. It will contain the code above to output these errors to the console instead of an alert.

Hi @Anybody & @drupalshrek, if you want to see any of these fixes go into D7, we really need to get #1533366: Simplify and optimize Drupal.ajax() instantiation and implementation committed. Other way to move things along is to provide an updated issue summary. Moving to postponed for now.

This is all because of Drupal's backport policy.

Thank you, heddn!

For the meantime here's a quick solution to prevent users from these alert popups:

I haven't followed this issue in the last couple months.

The error should not simply be hidden, but it should not show to end users. Showing to admins in a popup (or console.error) works for me. Loggiging all of them in watchdog also works for me.

But some kind of trace should be left if there are in fact errors.

I agree that the error message, as it is, should never be shown to users:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
ReadyState: 4

However, the problem is that there has been an error, and the other important fact is that sometimes (always?) this error causes the system to behave differently from how the user expects. In my case, pop-up links would not open at all. In that case I think it is actually a better user experience to be shown an error message (since then you know that something is going wrong), rather than no error message at all.

I would favour therefore a dual approach:

  1. log the current detailed message to watchdog
  2. pop up a user-friendly message such as "There has been an error and your request was not able to complete correctly."

Ultimately however, all this is really chopping at the leaves rather than dealing with the root: why does this error occur so much, and how can we fix it? If we can do that, then the hiding/logging etc. becomes much less of an issue.

drupalshrek: why does this error occur so much, and how can we fix it?

I admit not having read the whole thread (I found this URL after having debugged the problem on my own for a while), so my apologies if this is obvious and/or already has been mentioned, but a way to consistently reproduce this problem for me is this:


  • Drupal 7.26
  • A browser that is not Chrome

Steps to reproduce:

  1. User enters search string into autocomplete input field
  2. User waits for delay (default: 300ms) that triggers autocomplete AJAX request
  3. User submits form before the AJAX request returns

JavaScript code to trigger problem:

var sf = function () {
var rs = Math.random() .toString(36) .replace(/[^a-z]+/g, '');
setTimeout(sf, 310);


jQuery(function () {
    if (Drupal && Drupal.ACDB) { = function (searchString) {
            var db = this;
            this.searchString = searchString;
            // See if this string needs to be searched for anyway.
            searchString = searchString.replace(/^\s+|\s+$/, '');
            if (searchString.length <= 0 ||
                searchString.charAt(searchString.length - 1) == ',') {
            // See if this key has been searched for before.
            if (this.cache[searchString]) {
                return this.owner.found(this.cache[searchString]);
            // Initiate delayed search.
            if (this.timer) {
            this.timer = setTimeout(function () {
                // Ajax GET request for autocompletion. We use Drupal.encodePath instead of
                // encodeURIComponent to allow autocomplete search terms to contain slashes.
                    type: 'GET',
                    url: db.uri + '/' + Drupal.encodePath(searchString),
                    dataType: 'json',
                    success: function (matches) {
                        if (typeof matches.status == 'undefined' || matches.status != 0) {
                            db.cache[searchString] = matches;
                            // Verify if these are still the matches the user wants to see.
                            if (db.searchString == searchString) {
                    error: function (xmlhttp) {
                       // ORIGINAL LINE DELETED HERE
            }, this.delay);

User submits form before the AJAX request returns

… this is also our most common situation next to dying connections while editing long forms – happening for admins in Views UI as well regularly.

You must override Drupals ajax error functions with your custom message or no message at all or console log or whatever:

(function($, Drupal){
//Copy drupal's original error function for later use if you want
Drupal.ajax.prototype.original_error = Drupal.ajax.prototype.error;
Drupal.ajax.prototype.error = function (response, uri) {
if(response.readyState == 0){
alert('Your internet connection was lost.');
//Add more conditionals for the other readyStates if you want...I think 4 is the "terminated abnormally" that everyone is complaining about
//comment the next line out if you want to ignore Drupal's default ajax error method altogether
this.original_error(response, uri);
}(jQuery, Drupal));

@#173: "It does NOT ONLY suppress the core alerts, but also custom alerts." Overriding the entire window.alert may be too much for some users. I'm my case I still needed window.alert to work elsewhere. But that module would certainly do the trick in a "sledgehammer" sort of way. I just needed a more targeted "screwdriver" solution.

How about just getting the autocomplete part in? I've been running with the autocomplete part of this fix since August 2013. I was a little more nervous about putting in the ajax portion of the fix because it may have a wider impact. Also, by focusing on the autocomplete issue - here, or in a separate issue - , maybe we don't have to be delayed by a Drupal 8 rewrite of ajax framework?

As you can see in the summary, It's not the Drupal.ajax rewrite that delays this issue, it's #77245: A place for JavaScript status messages.

17: autocomplete-1232416-17-7x.patch queued for re-testing.

The last submitted patch, 17: autocomplete-1232416-17-7x.patch, failed testing.