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).

Proposed resolution

These alert boxes are a nuisance and something like console.log or watchdog would be a much better place to put these errors.

Per feedback in #236, #192, #169 and #161, and hinted at in #265, there are cases when there are indeed errors and it more ideal to print something to the user.

The solution landed on in #265 (and before too) accounts for the desire to still print the error when it is truly an error. And in all cases when the error isn't an error, give first preference to window.console and as a last resort, alert the user.

Remaining tasks

RTBC

User interface changes

Get rid of a nasty AJAX error.

API changes

n/a

Data model changes

n/a

Proposal solution

in /admin/config/development/logging
Have options to display ajax errors in console log or in alert.
see screenshot:

Comments

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.

@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).

@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.

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.

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.

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.

@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).

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.

@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).

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.

@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.

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 http://api.jquery.com/jQuery.ajax/, 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.

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.

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.

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.

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).

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 drupal.org - 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 :)

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.

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.

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. http://patik.com/blog/complete-cross-browser-console-log/) 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.

@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 drupal.org.

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 :/

@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.

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.

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...

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.

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.

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.

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:

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.

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...

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).

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.

@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.

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

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.

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.

#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.

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.)

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.

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:

log the current detailed message to watchdog

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:

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?

This issue seems to stem from ajax not actually terminating on select. let me explain

Set up an autocomplete field.
goto the page
select the field
type in some text, and select one of the options from the dropdown.
next click submit without clicking anything else.

This will cause the ajax terminated abnormally popup

now

reload the page
Select the field
type in some text, and select one of the options from the dropdown.
now re-click the field without typing anything
next click submit

This will alow the form to submit without any errors

It seems that without reselecting the field, the ajax call will never be completed so will only terminate on a page load, causing the error.

Doing this also fixes an error with autocomplete and unlimited items. without reselecting the fields, none of the items will be saved in the submission, but clicking each of the fields in a multi-autocomplete with the "add another item" button again before saving stops the error and also saves all the submission data.

I hope this helps

edit:

checking with firebug, the ajax will not terminate if the number of choices is too large.

so on my system, i have alot of users (10k+) with usernames all starting with 00. now if you type in 00, wait a moment, then carry on typing in the rest of the numbers (without unselecting the field) then the system will have two ajax requests. 00 and 00** (**= two other numbers)

These two ajax requests will be for the same field, but will cause the ajax termination error because while the 00** request completes and returns a result, which the user selects, the 00 request will still be running when they click submit.

Does anyone else approve or disapprove of splitting the #17 fix off to a new issue? (or at least the autocomplete part.) I don't think this fix should be postponed 3+ years. I think the current proposed solution of this issue should be labelled a new feature.

I'm experiencing this same problem with a site running 7.34. The patch in #17 removes the error display (which may be fine in some cases), but it doesn't do anything to fix the root cause. An example:

I'm using the Vehicle module to associate year/make/model information with a specific content type. The edit form for this content type allows me to add multiple year/make/model associations. It includes an "Add another item" button to add another set of form fields. Without the patch I get the "An AJAX HTTP request terminated abnormally" error when trying to "Add another item" and no fields are added. I have to save the content and start editing it again to get another set of empty fields. With the patch the error is suppressed, but no new fields are added. I've seen the same behavior when attempting to upload images using form-based inputs.

I've noticed that enabling the jQuery Update module will also eliminate the error for me. Unfortunately it produces a hang in which the spinning "Please wait..." never goes away and the additional form fields aren't added to the form.

Does anyone have any pointers to a fix for whatever is causing the error to be displayed in the first place?

I've found and fixed the issue that was causing the "An AJAX HTTP request terminated abnormally" message to appear on my site. The first thing I needed was a better understanding of the real error. I got that by adding a few lines to misc/ajax.js before line 172:

This adds an error handler that gets called before the "complete" handler that produces the warning that's the subject of this issue. The error handler produces a more detailed (depending on your browser) description of the underlying error; I've attached images of the error produced by Internet Explorer 11, Firefox 35, and Chrome 40. Internet Explorer produces a "Permission denied" error. Firefox produces a "Permission denied to access property 'document'" error. Chrome produces the most helpful error, "Blocked a frame with origin |my site| from accessing a cross-origin frame".

After seeing the error produced by Chrome I started digging into cross-origin frame issues. I found that my nginx configuration includes this line that I added a little while ago to improve site security:

add_header X-Frame-Options DENY;

This HTTP header tells browsers that "The page cannot be displayed in a frame, regardless of the site attempting to do so", and that's what was producing my "permission denied" errors. The solution was to change the header to this:

add_header X-Frame-Options SAMEORIGIN;

This header tells browsers that "The page can only be displayed in a frame on the same origin as the page itself". This is a little more liberal than DENY, but it still restricts display to frames and pages that originate from my site. After making this change and restarting nginx the problem has gone away completely!

I've been getting this AJAX error with file uploads and the issue was that I had recently configured the security kit X-frame-options to Allow-From when they had originally been SameOrigin. Changing them back worked.

It looks like the comment in #194 is recommending a change in a server setting. So unless you change that server setting to send those headers, no the error will not ever be removed. If that comment is correct, it is not something that the module has control over, but that has to be configured at the server level.

Type something in the city or postal code field. After typing, do NOT click or type anything else.

Click a navigational link ("Contact" or "Support") or any other non-checkout related link on the screen.

The AJAX popup will appear.

And my original thoughts on why this happened (I'm not a JS person, so I could be way off): "What this workflow does is send the browser into competition - as soon as the user "does another action" (in this case, clicking a link), the checkout process sends off an AJAX request. But then the browser starts resolving the user's click - going to another page entirely - and cancels or otherwise doesn't finish the AJAX request."

David_RothsteinCreditAttribution: David_Rothstein as a volunteer commented October 11, 2015 at 8:06pm

Status:

Reviewed & tested by the community

» Needs review

I read through this issue and am confused about where it ended up. We have comments from @drupalshrek (in #161 and #169) and @sah62 (in #192) suggesting that the "terminated abruptly" errors can indicate a real error that prevents something the user is trying to do from working at all.

So as suggested there, why isn't this patch showing them some kind of error message (but in a friendly way) and recording the technical details via console.log, rather than hiding it from the user entirely? (And if it should be doing the former, this would certainly apply to other Ajax errors too, not just the "terminated abruptly" variety.)

Based on this code, it looks like when the error described in this issue occurs (i.e. when xmlhttprequest.status is 0) there will be no feedback to the user, only a console.log. I also tested the patch and that seemed to be exactly how it behaved.

JaypanCreditAttribution: Jaypan at Jaypan commented October 12, 2015 at 2:36am

What exactly is a 'friendly way'? Alert messages are particularly obnoxious, and not friendly at all.

I've never seen this error pop up for a good reason. It's always something weird that doesn't have any benefit to the user whatsoever. I've been writing the error to the console for a couple of years now with no issue whatsoever on any sites.

If you have a good suggestion for it, I'm open ears, but in the mean time I think that this has been reviewed by enough people, and needs to be committed. I don't agree with the change to 'needs review', particularly when there is no suggestion on what should be done.

JaypanCreditAttribution: Jaypan at Jaypan commented October 12, 2015 at 2:40am

I should add, that this error does not provide any value to the end user, even when put out in a user friendly message. Conversely, putting a message such as 'there has been an error', when the action does actually proceed without issue, is bad UX.

It's better to hide this error altogether, writing to the log. If/when developers are getting this error preventing something from happening, they should work backwards to provide a better error than the one given. This particular error should not be shown to end users.

David_RothsteinCreditAttribution: David_Rothstein as a volunteer commented October 12, 2015 at 4:00am

Conversely, putting a message such as 'there has been an error', when the action does actually proceed without issue, is bad UX.

According to the comments I linked to above, the action does not proceed without an issue - it just silently fails instead?

An alert popup with something like "The action failed to complete" or similar would certainly be an improvement over the current situation. Alternatively some kind of error message inline on the page (which is exactly what we do on Ajax requests that produce an error message server-side) could work, although it would be more complicated and maybe not the right experience either.

JaypanCreditAttribution: Jaypan at Jaypan commented October 12, 2015 at 4:32am

According to the comments I linked to above, the action does not proceed without an issue - it just silently fails instead?

The problem is that this issue mostly happens even when there is no failure. One way to trigger it is to click directly from an autocomplete textfield to a submit button before the autocomplete has finished. This causes the error, even though the submit button works fine. The failure is that no values were returned for the autocomplete. Showing the user an error of 'the action failed to complete' when they click the submit button is confusing, especially since whatever they are submitting actually does work. It's bad UX.

If there are specific instances where this error is happening, and something actually is failing, this should be dealt with by the developer - and there will be a note in the log for the developer. Right now doing a blanket 'something failed' in every circumstance, particularly something as ubiquitous as with autocomplete fields, is bad UX.

FabianxCreditAttribution: Fabianx as a volunteer commented October 15, 2015 at 4:10pm

@David: We use a similar patch on many sites.

The problem is, autocomplete wants to complete in the background, but then the user clicks submit, which aborts that operation.

So it is a user action that aborts it:

- Leaving the page
- Submitting the form

Obviously there could be a legitimate AJAX request that the user would like to see completed, but the point is, the browser would leave the window anyway, so the user would not see the result of the request in any case, so the Http Status 0 is very useless information and very intrusive it being an alert.

geerlingguyCreditAttribution: geerlingguy as a volunteer and at Acquia commented November 20, 2015 at 9:34pm

I'm again brought back to this issue to copy out the patch URL and stick it in another site's make file... I wonder if we can't just switch to the other extreme for now—I think in the past four years, I might've seen two or three instances of this error appearing and indicating an actual problem (e.g. the site went down in the middle of a request). But 99% of the time, it's just been annoying and terrible UX.

Thus this patch is probably installed on 90%+ of the Drupal sites I've ever worked with. Can we commit it to stop the bad-UX-bleeding for D7, and maybe open a follow-up issue that people can work on if they so desire to make a more useful message if there actually is an error worth alerting the user over?

I'm sorry, I'm not sure what you mean by "change it back". Please could you be more specific about any problems you can see with either #232 (patch for 7.39+) or #250 (updated patch for previous versions).

Hi,
I just tested the latest patch and tried to improve it a bit, because I was seeing error messages for not failing request, or better, requests that seem to fail but no reason could be found in the response from the server. Hence, I made two changes:

Adjust the status of response to be greater than or equal to 400 which indicate errors.

JS sub-system maintainer is OK with this change and direction, see #247. We've got fairly unanimous support from many others, plus support from another core committer in #233. I'd mark this thing RTBC myself at this point but for two reasons.

I cleaned up the last patch and removed some stray white space. There's no interdiff because my tool wouldn't generate one on the whitespace.

And I'm sure that other's much more involved in this issue would love that honor.

Otherwise, I tested this out and it fixes the issue. Waiting for someone else at this point to RTBC this thing.

2. Main propose of this issue is to mute unrelated errors. We need not output to Console for developers. If we do, it should be a standard way: new Error / throw. ( If you're developers and hate these alert errors, you can use error libs to catch it or rewrite the alert() )

window.alert = function(msg) {
console.log(msg)
}

3. Network errors should tell end users. Although this is not a friendly message ATM, we still should do that. (another story)

temkinCreditAttribution: temkin as a volunteer commented April 14, 2016 at 7:22pm

There are so many people willing to have this addressed already, including me. What if we take an alternative approach. There is an admin page "Logging and Errors" (/admin/config/development/logging) that allows to configure whether errors and warnings should show up on the front-end. I suggest to add another config there that would allow to select where to output AJAX errors - alert or console. This way site admins will be able to define their desired behavior, and even override it in settings.php based on the environment (prod, stage, dev, etc).

For D8, we should replace window.alert with other popups libs. Or at least, it should be a custom API wrapper for it for whatever solution. I'm not sure if we possible to do it in D7 or not.

Personally, I'm disagreed to add a simple mute workaround (#283) for D7. It can be easily misused & misconfigured. Your editors & developers may be shared SAME admin role permissions, and Editors expected 404 error reports or other helpful messages (either from CORE or Modules).

temkinCreditAttribution: temkin as a volunteer commented April 29, 2016 at 3:01pm

I'm working on a patch for #283, but have a hard time figuring where is the best place to pass a config variable to a Drupal JS object. As far as I see misc/ajax.js is only added to pages with Ajax logic. It would make sense to add Ajax reporting configuration at the same time when ajax.js is added, but I haven't found that place yet. Any advice will be appreciated.

David_RothsteinCreditAttribution: David_Rothstein as a volunteer commented April 29, 2016 at 7:08pm

There is an admin page "Logging and Errors" (/admin/config/development/logging) that allows to configure whether errors and warnings should show up on the front-end. I suggest to add another config there that would allow to select where to output AJAX errors - alert or console.

I don't think the analogy is valid. That screen is for configuring whether things like PHP notices and warnings are displayed. But when the user tries to take an action and it fails (e.g. submits a form and there is a validation error) we never provide an option to suppress those messages. Forcing all Ajax errors to the console would have the effect of suppressing everything.

I agree with @droplet's comments, for example:

3. Network errors should tell end users. Although this is not a friendly message ATM, we still should do that. (another story)

That is part of what I was getting at with my earlier comments in this issue also.

Ideally, I think we'd want to:
(a) Hide the error entirely if it's expected to be pointless (e.g. the user interrupted their own autocomplete request by intentionally navigating away from the page), and
(b) Show an error message if something goes wrong that the user did not initiate themselves (e.g. a network error prevented their Ajax request from working).

If there's no technical way to distinguish those (or no relatively easy way) then we may have to compromise and defer that to a followup issue - but so far I'm not sure anyone's even researched that?

Thanks David. Although I agree with you that there may be a better way to determine Ajax error from user-initiated termination, I still vote for a suggested logic. Most if not all of the sites where I use the above mentioned patch doesn't require Ajax validation. Typical use case is that they are pulling or refreshing data. There cannot be an incorrect input from a user side. Therefore I don't see a reason why we should show an error to a user when there was no mistakes on their side.

At the same time I understand that in other cases somebody may need that. Therefore my current patch leaves alert message as a default output and only provides an option to change it to console. As a site owner I can make a weighted decision to have that. It's way easier this way rather than having to maintain a core patch on multiple sites.