Update from @nod_:

This issue is too many comments long. The original issue: "Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors" has been fixed in #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page.

Now for any other feature request, or discussion it needs to happen in #1419652: JavaScript logging and error reporting.

You could also check https://www.drupal.org/project/ajax_error_behavior, where most of the other initiatives and patches on this issue are bundled there.

Problem/Motivation (as of #269)

The following error is frequently run into with Drupal. Per #215, it does not apply to D8.

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText: 
ResponseText: 
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).

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:

CommentFileSizeAuthor
#389 1232416-autocomplete-for-drupal7x53.patch1.09 KBguddo
#360 drupal-alerts-reroll-for-D7.50-1232416-360.patch1.07 KBtimfernihough
#359 drupal-alerts-reroll-for-D7.50-1232416-299.patch1.07 KBtimfernihough
#341 interdiff-1232416-336-341.txt425 byteshanoii
#341 1232416-341.patch2.07 KBhanoii
#336 1232416-336-MANUAL-TESTING-HELPER-do-not-test.patch1.04 KBDavid_Rothstein
#336 1232416-336.patch2.06 KBDavid_Rothstein
#326 interdiff-1232416-322-326.txt929 byteshanoii
#326 drupal-drupal_alerts_an_ajax-1232416-326.patch5.88 KBhanoii
#324 interdiff-1232416-322-324.txt929 byteshanoii
#324 drupal-drupal_alerts_an_ajax-1232416-324.patch6.27 KBhanoii
#322 interdiff-1232416-320-322.txt1.81 KBhanoii
#322 drupal-drupal_alerts_an_ajax-1232416-322.patch4.98 KBhanoii
#320 interdiff-1232416-310-320.txt4.89 KBhanoii
#320 drupal-drupal_alerts_an_ajax-1232416-320.patch5.35 KBhanoii
#310 interdiff-1232416-308-310.txt514 byteshanoii
#310 drupal-drupal_alerts_an_ajax-1232416-310.patch5.04 KBhanoii
#308 drupal-drupal_alerts_an_ajax-1232416-308.patch4.71 KBmaximpodorov
#302 drupal-drupal_alerts_an_ajax-1232416-302.patch4.6 KBxurizaemon
#301 drupal-drupal_alerts_an_ajax-1232416-295.patch4.6 KBxurizaemon
#296 drupal_core_ajax_in_console.png73.46 KBedutrul
#295 drupal_alerts_an_ajax-1232416-295.patch3.78 KBtemkin
#282 drupal_alerts_an_ajax-1232416-282.patch1.4 KBdroplet
#281 drupal_alerts_an_ajax-1232416-281.patch1.18 KBjibran
#281 Screenshot from 2016-04-14 11-59-53.png96.35 KBjibran
#281 interdiff.txt1.49 KBjibran
#274 drupal_alerts_an_ajax-1232416-274.patch1.3 KBheddn
#272 drupal_alerts_an_ajax-1232416-272.patch0 bytesheddn
#270 drupal_alerts_an_ajax-1232416-270.patch1.35 KBheddn
#269 interdiff_232-265.txt1.36 KBheddn
#269 interdiff_232-253.txt1.91 KBheddn
#265 autocomplete_and_ajax.js_error-display_D7.43.patch2.66 KBehj-52n
#253 1232416-253.patch1.18 KBlokapujya
#253 1232416-253.patch1.18 KBlokapujya
#250 autocomplete-1232416-251-7.37.patch1.2 KBshowrx
#232 autocomplete-1232416-232-7x.patch2.59 KBmangy.fox
#231 IE8-WinXP-console-error.jpg75.79 KBnod_
#225 1232416-225.patch2.58 KBopdavies
#218 autocomplete-1232416-218-7.37.patch905 bytesnikunjkotecha
#212 autocomplete-1232416-17-7x-reroll.patch1.03 KBjoelpittet
#205 autocomplete-1232416-205-7x.patch2.39 KBmangy.fox
#194 ie-permission-denied-error.png5.82 KBsah62
#194 firefox-permission-denied-error.png1.89 KBsah62
#194 chrome-cross-origin-frame-error.png4.7 KBsah62
#192 form-elements.png7.38 KBsah62
#179 D7-fix_autocomplete_terminated_error-1232416-179-do-not-test.patch1.06 KBrooby
#156 fix_for_autocomplete_terminated_error-1232416-156.patch2.42 KBshabana.navas
#130 abort-xhr-1232416-130.patch941 bytesyechuah
#129 fixAjax.js_.txt1.77 KBattiks
#126 error message.PNG20.15 KBbentleychan
#110 core-js-drupal-log-1232416-110.patch6.65 KBjhedstrom
#100 core-js-drupal-log-1232416-100-D7.patch6.65 KBslashrsm
#85 core-js-drupal-log-1232416-85.patch7.17 KBnod_
#83 core-js-drupal-log-1232416-83.patch7.17 KBnod_
#72 core-js-drupal-log-1232416-71.patch4.74 KBnod_
#66 core-js-drupal-log-1232416-66.patch4.87 KBnod_
#61 core-js-drupal-log-1232416-61.patch4.87 KBnod_
#59 core-js-drupal-log-1232416-59.patch3.95 KBnod_
#48 ajax-error-display.patch2.1 KBeffulgentsia
#46 tmp.module.txt777 byteseffulgentsia
#17 autocomplete-1232416-17-7x.patch985 bytesgeerlingguy
#17 autocomplete-1232416-17-8x.patch985 bytesgeerlingguy
#16 autocomplete-1232416-16.patch976 bytesgeerlingguy
#11 autocomplete-1232416-11.patch952 bytesj0rd
#9 autocomplete-1232416-9.patch921 bytesorbiteleven
#62 core-js-drupal-log-1232416-62.patch4.81 KBleewillis77
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rfay’s picture

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’s picture

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

Bumping to 8.x-dev

j0rd’s picture

Testing to see if drupal.org has this problem as well.

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

tomogden’s picture

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

j0rd’s picture

@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

rfay’s picture

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.

j0rd’s picture

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) {
     $(this.progress.element).remove();

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.

rfay’s picture

@j0rd you have to attach the patch so it can be tested and applied. http://drupal.org/patch.

Then set the issue to "Needs review".

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

orbiteleven’s picture

Assigned: Unassigned » orbiteleven
Category: feature » bug
Status: Active » Needs review
FileSize
921 bytes

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.

j0rd’s picture

FileSize
952 bytes

Re-formatted patch?

rfay’s picture

Status: Needs work » Needs review
orbiteleven’s picture

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.

j0rd’s picture

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

rfay’s picture

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

geerlingguy’s picture

FileSize
976 bytes

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

geerlingguy’s picture

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!) :-)

j0rd’s picture

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.

rfay’s picture

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

rfay’s picture

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.

geerlingguy’s picture

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

rfay’s picture

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

kevinmanx’s picture

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?

kevinmanx’s picture

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

mdupont’s picture

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 http://drupal.org/node/707484 ).

j0rd’s picture

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

@kevinmanx

In linux you do:

cd /your/drupal/directory/public_html
wget http://drupal.org/files/issues/autocomplete-1232416-17-7x.patch
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.

rfay’s picture

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

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

rfay’s picture

geerlingguy’s picture

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

j0rd’s picture

@rfay sorry, I didn't change it. I think there's a bug in d.org 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.

j0rd’s picture

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.

j0rd’s picture

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.

TS79’s picture

+1 for final porting to D6

j0rd’s picture

D6 doesn't have this problem I believe.

geerlingguy’s picture

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

TS79’s picture

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

ParisLiakos’s picture

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

geerlingguy’s picture

Assigned: orbiteleven » geerlingguy

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

rfay’s picture

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.

rfay’s picture

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

j0rd’s picture

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.

rfay’s picture

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

j0rd’s picture

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

geerlingguy’s picture

Assigned: geerlingguy » Unassigned

Won't have time right now :-/

geerlingguy’s picture

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?

effulgentsia’s picture

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

nod_’s picture

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.

effulgentsia’s picture

FileSize
2.1 KB

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.

effulgentsia’s picture

Status: Needs work » Needs review
effulgentsia’s picture

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.

nod_’s picture

Linking to meta #1419652: 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.

mmitar’s picture

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

nod_’s picture

Status: Needs work » Postponed

Can't do anything about this issue without #1419652: JavaScript logging and error reporting

leewillis77’s picture

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.

nod_’s picture

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

tunny’s picture

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

effulgentsia’s picture

Title: Drupal alerts "An AJAX HTTP request terminated abnormally" when a link is clicked or form is submitted during an AJAX operation » Drupal 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.

nod_’s picture

Status: Active » Needs review
FileSize
3.95 KB

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.

nod_’s picture

Status: Needs work » Needs review
FileSize
4.87 KB

testbot should be happy now.

leewillis77’s picture

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?

nod_’s picture

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.

leewillis77’s picture

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.

AndyF’s picture

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

nod_’s picture

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.

terbs’s picture

Subscribing

rfay’s picture

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

terbs’s picture

Thank rfay! I didn't notice :)

Rade’s picture

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;
 };
nod_’s picture

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.

nod_’s picture

ok, with the patch now :p

Patricia_W’s picture

subscribe

magnusk’s picture

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.

attiks’s picture

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?

attiks’s picture

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

RobLoach’s picture

+++ 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) {
     $(this.progress.element).remove();

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.

urlaub’s picture

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.

attiks’s picture

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

urlaub’s picture

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

tanmayk’s picture

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

bjcooper’s picture

subscribing

nod_’s picture

Status: Needs work » Needs review
FileSize
7.17 KB

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.

attiks’s picture

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?

nod_’s picture

Status: Needs work » Needs review
FileSize
7.17 KB

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.

nod_’s picture

Status: Needs work » Needs review

That's some scary whitespace :D

attiks’s picture

moniuch’s picture

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

nod_’s picture

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.

nod_’s picture

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.

nod_’s picture

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.

bvanmeurs’s picture

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() {
  $.ajaxSetup({
    beforeSend: function(jqXHR, settings) {
      settings.error = function(jqXHR, textStatus, errorThrown) {console.log('ajax error: ' + textStatus);};
    },
  });
});

})(jQuery);

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.

splatterb0y’s picture

Status: Postponed » Needs review
tim.plunkett’s picture

Status: Needs review » Postponed
iamEAP’s picture

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.

seutje’s picture

+// 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 (http://benalman.com/projects/javascript-debug-console-log/), 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.

tmsimont’s picture

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

(function($){
	Drupal.behaviors.YourThemeNameOrWhatever = (function(){
		return {
			attach:function(context, settings){		
				$.ajaxSetup({
					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);};
					  };
					}
				});
			}
		}
	})();
})(jQuery);

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

seutje’s picture

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.

slashrsm’s picture

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

kgogineni’s picture

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.

slashrsm’s picture

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

Lets test last patch....

slashrsm’s picture

nod_’s picture

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.

slashrsm’s picture

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.

Sorry....

slashrsm’s picture

Issue summary: View changes

Updated issue summary.

geerlingguy’s picture

Status: Postponed » Needs review
nod_’s picture

Status: Needs review » Postponed
nod_’s picture

Issue summary: View changes

Removed postponed text.

geerlingguy’s picture

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

jhedstrom’s picture

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.

osopolar’s picture

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:
      // http://drupal.org/node/1232416#comment-6165578 (#98)
      $.ajaxSetup({
        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.
          };
        }
      });
    }
  };
})(jQuery);
choitz’s picture

Status: Postponed » Needs review
choitz’s picture

Status: Needs work » Needs review

Hi,

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.

hardcoredev’s picture

Status: Needs review » Needs work

#111 works for me. Thanks!

leanderl’s picture

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.

seutje’s picture

@#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);}};
leanderl’s picture

@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 ($) {
   $(document).ready(function(){
      window.alert = function(arg) { if (window.console && console.log) { console.log(arg);}};
   }); // END document ready
})(jQuery);

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 ($) {
   $(document).ready(function(){
   }); // END document ready
})(jQuery);

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

seutje’s picture

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

netflarehq’s picture

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

leanderl’s picture

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

nod_’s picture

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.

deanflory’s picture

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.

deanflory’s picture

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.

_vid’s picture

@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
 * http://drupal.org/node/1232416 - 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
      
      $.ajaxSetup({
        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
})(jQuery);
bentleychan’s picture

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

spessex’s picture

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.

tmsimont’s picture

@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

attiks’s picture

Issue tags: -Needs backport to D7
FileSize
1.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.

yechuah’s picture

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

patch misc/autocomplete.js to allow abort

nod_’s picture

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

See #122.

BouM’s picture

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.

nod_’s picture

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.

edutrul’s picture

The solution in #129 is not working for me

Any Idea to resolve this issue on dr7?

tmsimont’s picture

try the one in #125

edutrul’s picture

I tried the following:

window.alert = function() {};

And I was able to delete that annoying warning.

liza’s picture

sorry, what line?

nod_’s picture

jenlampton’s picture

Issue tags: +Needs backport to D7

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

skt’s picture

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

allvip’s picture

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

I manually apply the patch.

1.in folder misc/ajax.js
find alert(Drupal.ajaxError(response, uri)); and replace with:


  if (response.status != 0) {
    alert(Drupal.ajaxError(response, uri));
 }

2.in 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):
https://drupal.org/node/534548

Kgaut’s picture

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

onyxnz’s picture

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.

onyxnz’s picture

Issue summary: View changes

Added new blocking issues.

Kerem O’s picture

Status: Postponed » Needs review

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

achauhan’s picture

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
ResponseText:
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
Home
Hello Astha
Log out
Administrative toolbarProductsActionsManage products
Add a product
SettingsCategories
Variation types
OrdersActionsManage orders
Add an order
ContentActionsManage content
Manage comments
Add content
SettingsContent types
Store settingsAdvanced store settingsCustomer profiles
Shipping
Taxes
Payment methods
Checkout settings
Currency settings
Line item types
Order settings
Pricing rules
Commerce Search API
Reset
Product settingsCategories
Variation types
PromotionsDiscounts
Site settingsVisual & LayoutAppearance
Blocks
Views
Advanced settingsStructure
People
Modules
Configuration
Site reports
Help
Marketplace
Help
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
Fields
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
Relationships
Edit Commerce Order: Line items
Add new
Empty
Total: 0.00 INR
Checkout
Edit view
Configure block
Configure block
Proudly built by Commerce Guys
Configure block
Powered by Drupal Commerce "
Kindly post any relevant information asap.

pingers’s picture

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.

funana’s picture

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

nod_’s picture

Status: Needs review » Postponed
nod_’s picture

Issue summary: View changes

update dependant issue list

Fabianx’s picture

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

Stolzenhain’s picture

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.

Anybody’s picture

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.

Anybody’s picture

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

Anybody’s picture

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"!

shabana.navas’s picture

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

klonos’s picture

Anybody’s picture

#156 works perfectly for 7.24

Exploratus’s picture

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

Anybody’s picture

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

drupalshrek’s picture

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

drupalshrek’s picture

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.

Anybody’s picture

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!

Anybody’s picture

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);
}
Anybody’s picture

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.

heddn’s picture

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.

Anybody’s picture

Thank you, heddn!

For the meantime here's a quick solution to prevent users from these alert popups:
https://drupal.org/project/prevent_js_alerts

j0rd’s picture

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.

drupalshrek’s picture

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
StatusText:
ResponseText:
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.

cconrad’s picture

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:

Prerequisites:

  • 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 () {
    jQuery("#ID_OF_FORM_SUBMIT_BUTTON").click();
};

var rs = Math.random() .toString(36) .replace(/[^a-z]+/g, '');
var n = jQuery("#ID_OF_AUTOCOMPLETE_INPUT_FIELD");
n.val(rs);
n.keyup();
setTimeout(sf, 310);

Workaround:

jQuery(function () {
    if (Drupal && Drupal.ACDB) {
        Drupal.ACDB.prototype.search = 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) == ',') {
                return;
            }

            // 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) {
                clearTimeout(this.timer);
            }
            this.timer = setTimeout(function () {
                db.owner.setStatus('begin');

                // Ajax GET request for autocompletion. We use Drupal.encodePath instead of
                // encodeURIComponent to allow autocomplete search terms to contain slashes.
                $.ajax({
                    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) {
                                db.owner.found(matches);
                            }
                            db.owner.setStatus('found');
                        }
                    },
                    error: function (xmlhttp) {
                       // ORIGINAL LINE DELETED HERE
                    }
                });
            }, this.delay);
        };
    }
});
Stolzenhain’s picture

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.

jduhls’s picture

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));
Anybody’s picture

jduhls’s picture

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

lokapujya’s picture

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?

nod_’s picture

As you can see in the summary, It's not the Drupal.ajax rewrite that delays this issue, it's #77245: Provide a common API for displaying JavaScript messages.

das.gautam’s picture

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

rooby’s picture

Here is the patch from #156 (which was from #17) without the unrelated white-space hunks.

This patch is for Drupal 7 and is only for addressing these error messages in the case of autocomplete fields.

DocDJ-forum’s picture

I am getting these AJAX errors during Commerce Kickstart install in the stage: Configure store/create & finish. I have been fighting this for a week. I have checked my PHP and MySQL installs and they work perfectly. I am installing on my own Apache server on Windows 7 X64. Apache is working properly (I've been running this website for over 10 years). I have allowed 10 minutes for PHP scripts on a quad-core 3.25GHz PC, so it should be done a others have indicated. If I click on "continue to the error page", I get to Import Content and then I get more AJAX errors. The messages contain various versions of:
Call to undefined function commerce_kickstart_taxonomy_term_path() where the "undefined function" name changes with each message.
Eventually, I get the error:
"This page can’t be displayed" for the address: http://dforeman.homedns.org/~dj/drupal/install.php?profile=commerce_kick...

I am SOOO frustrated with this Kickstart process. Is there a way of bypassing AJAX? Am I missing some concept in PHP or MySQL?
Kickstart is "supposed" to get you up and running fast. I have never had to spend a full week doing an install of ANYTHING in over 30 years of programming and IT support. I am not knowledgeable in PHP, so I can't (& shouldn't have to) start reading the code to try to fix it for a basic installation.

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

imre.horjan’s picture

I've written a sandbox module for Drupal 7 based on this solution, which works for Ajax and Autocomplete fields. (Different approach than Prevent JS Alerts module)
Check it out here: https://www.drupal.org/sandbox/imre.horjan/2327755

LeeUDO’s picture

This might be some help to the maintainers,

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.

kalidasan’s picture

+

jenlampton’s picture

patch in #17 still applies to 7.32.

No Sssweat’s picture

#183 worked for me, great solution, cheers!

ahimsauzi’s picture

Was #17 included in 7.34 or is that too soon?

lokapujya’s picture

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.

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

sah62’s picture

FileSize
7.38 KB

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?

ehsankhfr’s picture

#183 worked here either! :D Thanks!

sah62’s picture

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:

error: function (request, status, error) {
  alert(request.responseText + " " + status + " " + error);
},

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 hope this helps anyone who's been struggling with this issue.

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

swhitters’s picture

Thank you, thank you #194!

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.

sah62’s picture

Thank you, thank you #194!

You're very welcome.

davidwbarratt’s picture

What's the status of this, will this error message ever be removed?

DrCord’s picture

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.

Arlina’s picture

#194 did the trick for me.
The config can also be set at .htaccess level with the following (needs apache with the mod_headers enabled):

<IfModule mod_headers.c>
  Header append X-Frame-Options SAMEORIGIN
</IfModule>
Andrzej7’s picture

Thanks to everybody for your commitment. This error is popping up sometimes (can't guess, why ana sometimes not).

I applied all 3 solutions
- ajax_error_suppress module
- prevent_js_alerts module
- #17 (and #156)

The error didn't pop up. BUT the autocomplete stopped. Ajax doesn't work in the field. I don't know is it better or worse for users trying to add tags?

P.S. Problem is in Chrome, not in Firefox

joelpittet’s picture

Status: Postponed » Needs review

This shouldn't be postponed anymore.

mangy.fox’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

Patch #17 7.x no longer applies to core 7.39.

mangy.fox’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
2.39 KB

Re-rolled patch from #17 against 7.39

Status: Needs review » Needs work

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

mangy.fox’s picture

Version: 8.0.x-dev » 7.x-dev
Status: Needs work » Needs review

Changing version for patch test purposes.

mangy.fox’s picture

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

Patch passed testing against 7.x.

Set back to 8.x for further work.

darrenwh’s picture

Version: 8.0.x-dev » 7.39
Status: Needs review » Reviewed & tested by the community

This patch applied successfully on 7.38 to 7.39 update (autocomplete-1232416-205-7x.patch)

opdavies’s picture

Version: 7.39 » 8.0.x-dev
Status: Reviewed & tested by the community » Needs work

This needs to be fixed in 8.0.x first, and back-ported. Sorry!

catch's suggestion in IRC:

so I'd be tempted to get a version of that patch into both versions then open an 8.x follow-up for the clean up.

joelpittet’s picture

Version: 8.0.x-dev » 7.x-dev
Status: Needs work » Needs review
FileSize
1.03 KB

Re-rolled #17 7.x.

joelpittet’s picture

Version: 7.x-dev » 8.0.x-dev
joelpittet’s picture

oh sorry @mangy.fox already did this :S

joelpittet’s picture

Version: 8.0.x-dev » 7.x-dev
Issue tags: -Needs backport to D7

Ok tried to re-roll for D8 but it looks like both ajax.js and autocomplete.js have taken different approaches to deal with the status and both don't issue alert() for the errors.

So moving to D7 for good, hopefully that is ok @opdavies?

Status: Needs review » Needs work

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

Andrzej7’s picture

Thank you mangy.fox
#205 works for me :-)

nikunjkotecha’s picture

Patch for Drupal 7.37

lokapujya’s picture

+++ b/misc/ajax.js
@@ -448,7 +448,10 @@
+  ¶

white space.

joelpittet’s picture

Status: Needs work » Reviewed & tested by the community

#205 from @mangy.fox should be good to go. I hid mine and @nikunjkotecha's patches.

joshuautley’s picture

RTBC. Looks good.

Andrzej7’s picture

After some days of practice with the patch, I see that sometimes the autocomplete function works, sometimes not. The difference after the patch is - no error message.

But... without autocomplete function the tagging field is useless. Any chance for solving the problem, to make autocomplete work properly?

Jaypan’s picture

Status: Reviewed & tested by the community » Needs work

I think the patch from 205 needs a little more work. This:

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

Should be revised to this:

if (xmlhttp.status) {
  alert(Drupal.ajaxError(xmlhttp, db.uri));
}
else if (console) {
  console.log(Drupal.ajaxError(xmlhttp, db.uri));
}

This will print the error 0 to the console, so that it isn't lost altogether.

After some days of practice with the patch, I see that sometimes the autocomplete function works, sometimes not. The difference after the patch is - no error message.

There is nothing in this patch that would cause an error with autocomplete, it just suppresses the error zero reporting. So your error must be somewhere else.

nod_’s picture

Jaypan is right. That's a patch I'd RTBC.

opdavies’s picture

Status: Needs work » Needs review
FileSize
2.58 KB

Here's an updated patch using else if and console.log() in both files, as suggested in #223.

Team effort with mangy.fox. :)

davidwbarratt’s picture

Status: Needs review » Needs work

You can't use console.log() because Drupal 7 supports IE 8 & 9:
http://stackoverflow.com/a/5473193/864374

You could add a test to see if the console object and log method are available first.

Jaypan’s picture

Status: Needs work » Needs review

You can't use console.log() because Drupal 7 supports IE 7 & 8:

That's why the code is first checking to see if console exists:

else if (console)

In IE7 and IE8, console evaluates to false, and the call to console.log() is not made.

davidwbarratt’s picture

Ah! I see that now, sorry for jumping the gun. :)

nod_’s picture

Status: Needs review » Needs work

it should be else if (window.console) otherwise it'd fail on oldIE.

Jaypan’s picture

if (console) will work on IE7 & IE8

nod_’s picture

FileSize
75.79 KB

on oldIE console is only defined when dev tools are open. You need window.console to avoid a JS error. See attached screenshot of the error on IE8 / WinXP.

mangy.fox’s picture

Status: Needs work » Needs review
FileSize
2.59 KB

Agreed - changed to window.console

nod_’s picture

Status: Needs review » Reviewed & tested by the community

Thanks.

Talked with catch on IRC a few days ago, we agreed it's an acceptable compromise on D7.

Morbus Iff’s picture

Sadly, my test case for this (an Ubercart install with lots of extras) fails the revised patch. 17 worked fine (prior to core 7.39). 232 shows the AJAX error popup reproducibly. Whether it's reproducible on anyone else's system, no idea. My own internal notes are akin to:

  1. Go to Ubercart site.
  2. Put something in your cart.
  3. Head to checkout.
  4. Type something in the city or postal code field. After typing, do NOT click or type anything else.
  5. Click a navigational link ("Contact" or "Support") or any other non-checkout related link on the screen.
  6. 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."

Morbus Iff’s picture

Ignore previous comment. Can no longer reproduce. I blame the cache. ;)

David_Rothstein’s picture

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

Jaypan’s picture

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?

It is. You need to re-review.

David_Rothstein’s picture

+  if (xmlhttprequest.status) {
+    alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  }
+  else if (window.console) {
+    console.log(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  }

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.

Jaypan’s picture

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.

Jaypan’s picture

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_Rothstein’s picture

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.

Jaypan’s picture

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.

cilefen’s picture

Issue tags: +JavaScript
Fabianx’s picture

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

geerlingguy’s picture

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?

Jaypan’s picture

Status: Needs review » Reviewed & tested by the community
nod_’s picture

Yes please, let's get this one done.

lokapujya’s picture

Put in in!

showrx’s picture

Updated patch for Drupal 7.37 with console.log.

showrx’s picture

Updated patch for Drupal 7.37 with console.log.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 250: autocomplete-1232416-251-7.37.patch, failed testing.

The last submitted patch, 250: autocomplete-1232416-251-7.37.patch, failed testing.

lokapujya’s picture

The last submitted patch, 253: 1232416-253.patch, failed testing.

lokapujya’s picture

WTF? same patch and one has a seemingly unrelated test fail?

The last submitted patch, 253: 1232416-253.patch, failed testing.

mfuller526’s picture

This thread helped me: drupal.org/node/1069800

Bottomline - redirects in .htaccess MUST match the base_url. If you choose in .htaccess to direct all users to www.example.com, the base_url in site/default/settings.php MUST be www.example.com

marc.groth’s picture

Status: Needs review » Reviewed & tested by the community

I have had this same issue occur intermittently throughout a number of projects.

After applying patch #253 and clearing the cache, there are no more errors!

Thanks to everybody who helped make this happen. It would be amazing if this could be committed.

matt.rad’s picture

+1 for getting this committed. I have a lot of end users confused/put off by these unnecessary messages.

hgoto’s picture

I also tested the patch #253 with Chrome. It fixes the problem and works fine. +1 for commit.

mangy.fox’s picture

I can't see how #253 is an improvement over #232? It had already been RTBC in #246. From what I can see, #253 will break in ajax.js due to 'response' not being defined.

lokapujya’s picture

Looks like the patch in #250 did that mistakenly. Please change it back.

mangy.fox’s picture

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

lokapujya’s picture

Oh, I see. #250 was for a previous version, but the issue version didn't change and that's why it failed to apply. I didn't need to reroll it. I guess we should just ignore #253.

RTBC for #232.

ehj-52n’s picture

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:

  1. Adjust the status of response to be greater than or equal to 400 which indicate errors.
  2. Move the console.log statement before the alert statement.

Hope, this helps.

In my case, it did. Feel free to comment and thanks for your time.

geerlingguy’s picture

Status: Reviewed & tested by the community » Needs review

Can you post an interdiff, so we can see the changes made since the last patch?

mgifford’s picture

heddn’s picture

Here's a couple interdiffs against #232 for both #253 & #265.

heddn’s picture

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.

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

Lastly, issue summary is now updated.

Status: Needs review » Needs work

The last submitted patch, 270: drupal_alerts_an_ajax-1232416-270.patch, failed testing.

heddn’s picture

Status: Needs work » Needs review
FileSize
0 bytes

Status: Needs review » Needs work

The last submitted patch, 272: drupal_alerts_an_ajax-1232416-272.patch, failed testing.

heddn’s picture

Status: Needs work » Needs review
FileSize
1.3 KB
jibran’s picture

Status: Needs review » Reviewed & tested by the community

I have been using it on a production site for quite a while now. It works great. Thank you @heddn for the re-roll.

geerlingguy’s picture

I'll second the RTBC; I don't think I've seen a site launch in the past few months (years) _without_ this core patch. It's added by default in many distributions' make/patch files.

nod_’s picture

Looks good to me too.

JordanMagnuson’s picture

I've also been using this patch in production for a long time. Would love to see it committed.

smndey’s picture

It works. It would be amazing if this could be committed.

Jaypan’s picture

Works for me too.

jibran’s picture

+++ b/misc/ajax.js
@@ -476,7 +476,14 @@ Drupal.ajax.prototype.getEffect = function (response) {
+  if (xmlhttprequest.status >= 400) {

This check is not correct in case of any run time error or syntax error the status code is 0.

droplet’s picture

Shouldn't this way ?

1. These errors aren't real error from scripting. we shouldn't log it.

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)

temkin’s picture

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

Thoughts?

Jaypan’s picture

That's a good suggestion.

lionslair’s picture

Agree good suggestion

droplet’s picture

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

Note that,
1. both of my Chrome & Firefox are enabled Console by default. Same to you?
2. To be clarified, above patch already muted unexpected ajax.abort() alerts.

jibran’s picture

Status: Needs review » Needs work
Issue tags: +JavaScriptTest, +Needs tests
temkin’s picture

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.

cilefen’s picture

It may be Drupal\Core\Render\Element\RenderElement

temkin’s picture

Thanks @cilefen, but this issue is for D7. Do you know where to put it there?

cilefen’s picture

ajax_pre_render_element()

David_Rothstein’s picture

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?

Here's some quick research suggesting it could be possible:

http://ilikestuffblog.com/2009/11/30/how-to-distinguish-a-user-aborted-a...
http://stackoverflow.com/questions/3648309/how-to-detect-if-a-request-wa...
http://stackoverflow.com/questions/4807572/jquery-ajax-error-handling-to...

And a couple other references (not as directly relevant):

http://stackoverflow.com/questions/3825581/does-an-http-status-code-of-0...
http://stackoverflow.com/questions/2496275/in-xmlhttprequest-where-is-er...

David_Rothstein’s picture

Status: Needs work » Needs review
Issue tags: -JavaScriptTest, -Needs tests

Also we don't currently have a way to write automated JavaScript tests for Drupal 7.

jibran’s picture

Sorry, I keep on mixing it with d8 bugs.

temkin’s picture

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.

edutrul’s picture

Issue summary: View changes
FileSize
73.46 KB

I've just tested patch #295 and works like a charm!

Proposal solution

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

Thanks all people for doing this possible!

ibuildit’s picture

Works for me too!

ibuildit’s picture

Actually, it works, until I reload the page, then the error appears again.

Unfortunately this fix is pure black magic to me but I bet someone here knows how to prevent it.

I'm using views autorefresh.

Thanks for all your great work on this.

SKAUGHT’s picture

-  alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  if (Drupal.settings.ajaxErrorDisplay === "1" && window.console) {
+    console.log(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  }
+  else {
+    alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  }

perhaps it shouldn't be checking for setting && console. (but deal with the fact that console is/isn't defined, secondarily):

-  alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  if (Drupal.settings.ajaxErrorDisplay == 1) {
+    if(typeof(console) !== 'undefined'){
+       console.log(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+    }
+  }
+  else {
+    alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+  }

yes, the message may not make it out if there's a console error, but ensures it won't leak to alert.

MastaP’s picture

Ok, so the only solution here is really to patch the core!?

xurizaemon’s picture

Per @SKAUGHT above. The current patch referred to both window.console and console; I'm not sure if either is "more" correct, but went with window.console - does it ever matter?

Currently settings saved as ajax_error_level are 0=alert, 1=console, and that feels backwards; I feel like the alert output (current default) should be a higher number than console, since it's more visible / "noisier", and not true/false-y.

@ibuildit if you are still seeing issues with this patch applied, now's the time to help make sure your itch gets scratched before it gets committed :D

Oops, messed up my patch filename sorry, should be -301.patch :(

xurizaemon’s picture

The last submitted patch, 282: drupal_alerts_an_ajax-1232416-282.patch, failed testing.

Fabianx’s picture

Issue tags: +Drupal bugfix target

Targeting for a bugfix release.

michalgreksak’s picture

I had this error:

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

always at the time when I edit/add node and spent 3 days looking for the reason of that.
This happened after we move our site to the ssl version (https:)

I was wondering why I have no error log anywhere in my servers php, mysql, nginx log's and I finally found the problem message was only in the console of the browser. There was a log:
Refused to display 'https://www.my.domain/system/ajax' in a frame because it set 'X-Frame-Options' to 'DENY'.

After that I looked into my new configuration of ssl in nginx and set it up From:
add_header X-Frame-Options DENY;
To:
add_header X-Frame-Options SAMEORIGIN;

This was my solution, maybe can somebody help.

star-szr’s picture

We tested #302 and in our situation the Drupal settings set via ajax_pre_render_element() were not present so Drupal.settings.ajaxErrorDisplay was always undefined.

Not sure if it's because it's Views ajax or not but we ended up doing this to ensure the settings were passed:

$element['#attached']['js'][] = array(
  'type' => 'setting',
  'data' => array(
    'ajaxErrorDisplay' => variable_get('ajax_error_level', 1),
  ),
);
drupal_render($element);
maximpodorov’s picture

Status: Needs review » Needs work

ajax_pre_render_element() is used for form elements only. So for the custom code which uses Drupal AJAX framework, this solution is incomplete.

I suggest to add this setting in system_library() for 'drupal.ajax' library.

maximpodorov’s picture

Status: Needs work » Needs review
FileSize
4.71 KB

This patch moves settings attachment from ajax_pre_render_element() to 'drupal.ajax' library definition in system_library().

Status: Needs review » Needs work

The last submitted patch, 308: drupal-drupal_alerts_an_ajax-1232416-308.patch, failed testing.

hanoii’s picture

Nice change @maximpodorov! drupal.autcomplete should also have the settings added.

hanoii’s picture

Status: Needs work » Needs review
maximpodorov’s picture

@hanoii, yes, you're right.

Fabianx’s picture

Thanks all for working on this, fly by review:

  1. +++ b/includes/bootstrap.inc
    @@ -41,6 +41,16 @@ define('ERROR_REPORTING_DISPLAY_SOME', 1);
    + * Ajax error reporting level: display errors is alert window.
    

    nit - typo is => in

  2. +++ b/includes/bootstrap.inc
    @@ -41,6 +41,16 @@ define('ERROR_REPORTING_DISPLAY_SOME', 1);
    +define('AJAX_ERROR_REPORTING_ALERT', 0);
    ...
    +define('AJAX_ERROR_REPORTING_CONSOLE', 1);
    

    I agree we should swap that.

  3. +++ b/misc/ajax.js
    @@ -476,7 +476,15 @@ Drupal.ajax.prototype.getEffect = function (response) {
    +  if (Drupal.settings.ajaxErrorDisplay === '1') {
    
    +++ b/misc/autocomplete.js
    @@ -310,7 +310,14 @@ Drupal.ACDB.prototype.search = function (searchString) {
    +        if (Drupal.settings.ajaxErrorDisplay === '1') {
    

    Kinda strange to check this as a string if we put in an int in Drupal ...

hanoii’s picture

@Fabianx as for 2, swap what? the order, or the values?

Fabianx’s picture

#315: The values and the order.

I think usually alerting === 1 (higher), than just debug logging (0).

Kinda arbitrary, but how I feel it would be right.

If there are good arguments against it, happy to leave as is though.

temkin’s picture

My original thought was to keep current logic (alerting) at 0 in order not to change this logic for people who may rely on those alerts and are not aware of a new configuration. I hate those alerts personally, but I think it should be an explicit decision to turn them off since they were in Drupal for so long and as I said somebody may rely on them.

Just a thought...

hanoii’s picture

@temkin I believe what number you give to the constant doesn't keep you from keeping the default behaviour as it is now, which is how it should be.

Will see to these requests.

temkin’s picture

True. But code looks better this way :-)

if (Drupal.settings.ajaxErrorDisplay === '1') {
  ...
  window.console.log(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
  ...
}
else {
  alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
}
hanoii’s picture

I went a little bit further with this patch. Sorry.

I reworked a bit the logic to have one single function where if clause is done I reworded some of the texts and config a bit. I do think it's cleaner though.

The interdiff got bigger than the actual patch.

I also addresses most of the reviews done on #316.

marc.groth’s picture

Status: Needs review » Reviewed & tested by the community

Patch #320 applies cleanly and works like a charm.

Thanks so much everyone (especially hanoli) for all your work on this!

hanoii’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
4.98 KB
1.81 KB

I reworked it a bit more. By adding a Drupal.alert function, it made sense to have the javascript error setting always as opposed only to be used with ajax. Just in case Drupal.alert is used by anyone else in the future.

@marc.groth if you can test it again, that'd be great!

Status: Needs review » Needs work

The last submitted patch, 322: drupal-drupal_alerts_an_ajax-1232416-322.patch, failed testing.

hanoii’s picture

Status: Needs review » Needs work

The last submitted patch, 324: drupal-drupal_alerts_an_ajax-1232416-324.patch, failed testing.

hanoii’s picture

hanoii’s picture

Status: Needs work » Needs review
marc.groth’s picture

Status: Needs review » Reviewed & tested by the community

Patch #326 also applies cleanly and works perfectly; good work!

drupal_newb’s picture

I'm a total beginner but am having the same problem with submitting a comment form and using views autorefresh/nodejs. Everything works fine except the occasional alert box.

Looks like I have to edit the core. Can some one provide the patched files that I need to replace? Thanks!

marc.groth’s picture

@drupal_newb you'll need to apply the latest patch (see comment #326 or the first file under the 'Files' section at the bottom of the issue description) which changes core files. A good article on applying patches is here: https://www.drupal.org/patch/apply. You should never hack core directly. Always find a way around it or if it's a genuine bug in Drupal (such as this one) then create an issue so a patch can be created. In this case these changes are intended to go into core so it isn't a problem.

Once you've applied your changes it would be good if you could confirm that the patch works for you with your set up. If it doesn't, please update the status of this issue to 'Needs Work' along with any applicable information for someone to be able to replicate the issue; so they can fix it and re-patch.

Fabianx’s picture

I am very +1 to the latest patch. That feels very clean.

One thing:

+++ b/modules/system/system.admin.inc
@@ -1676,6 +1676,17 @@ function system_logging_settings() {
+  $form['js_error_level'] = array(
...
+    '#default_value' => variable_get('js_error_level', JS_ERROR_REPORTING_ALERT),

I wonder if we want to document that in settings.php as well.

I think we do so for most settings.

Fabianx’s picture

Status: Reviewed & tested by the community » Needs review

The patch is really good - as already said, however we (Stefan and me) wondered if it would not be better to use three levels:

ALERT_ALL, ALERT, CONSOLE

With ALERT being distinguished from ALERT_ALL that the dreaded error "0" would be alert()'ed for ALERT_ALL and logged (if possible) for ALERT.

I think this is better for cases, where some user feedback is wanted, but the error "0" is gone.

Drupal.alert, which I very much agree with would need a 2nd optional parameter (error_code) in that case.

But that should be fine and the logic is not too complicated.

Thoughts?

Fabianx’s picture

Assigned: Unassigned » David_Rothstein

Assigning to David to chime in, too

David_Rothstein’s picture

Assigned: David_Rothstein » Unassigned

There are several misspelled words in the user-facing text ("JavaScript", "Ajax", "behavior") and some unusual phrasing in the #description. Also the entire #description seems unnecessary since it could just be incorporated into the above instead (i.e. "JavaScript behavior for Ajax errors" => "Show in an alert window" or "Log to the browser console").

A bigger issue is my concern in #292, which hasn't really been addressed. I do agree with #295 that there are cases where you wouldn't want any kind of error to show at all, but that's something that depends on the particular Ajax request so it's something the developer should decide, not something that should be a sitewide setting. (For example, if a user tries to submit an Ajax form and it fails, they should be notified of that, but something like an inconsequential block at the bottom of the page which loads automatically via Ajax and fails... probably reasonable not to display an error in that case). I think only the developer can decide which is which, so making it easier for developers to skip alerts for a particular Ajax request is a reasonable goal but better done as a separate issue from this one. (Per the title this issue is really just supposed to be about making sure the specific incorrect alert message doesn't appear during normal site operation.)

Jaypan’s picture

I predict this issue will never be resolved.

David_Rothstein’s picture

We already have a patch from @droplet in #282 that implements one of the ideas from the links in #292. However I tested it and it didn't work correctly (it suppressed the desired error, but suppressed network errors also - as some of the comments in those links suggested it would).

So here's a patch that uses an approach from one of the other links in that comment. It worked for me. To test this, I did the following:

  • Apply the attached "manual-testing-helper" patch (in addition to the patch itself)... this inserts a sleep() call which delays the Ajax response by 20 seconds and therefore allows you to more easily test a particular Ajax request (via the "Format" dropdown on the Manage Display page, e.g. at admin/structure/types/manage/page/display) or a particular autocomplete Ajax request (via the "Authored by" field on the node page, e.g. at node/add/page) with enough time to actually interrupt the request.
  • If you trigger one of those Ajax requests and then either navigate away from the page or reload the page while the request is still in progress, you should find that the alert message no longer displays (thereby fixing the bug in this issue).
  • Whereas if you trigger the Ajax request and then simulate a network error (for example, by shutting down Apache while the request is still in progress) the alert message should still be displayed and thereby give the user notice that something went wrong.

So I think this is working correctly, but I only tested in Firefox. Some comments on the Stack Overflow post (http://stackoverflow.com/questions/699941/handle-ajax-error-when-a-user-...) indicate that this won't work on mobile Safari, which I did not test (and they suggest some more complicated solutions to make it work there too). Not sure if that's still an issue in newer versions of mobile Safari though.

Fabianx’s picture

Status: Needs review » Reviewed & tested by the community

RTBC - lets get this patch in for now first.

For iOS, they now support onunload, but deprecated it in favor of pagehide event.

https://developer.apple.com/library/ios/documentation/AppleApplications/...

So maybe we should just listen for both?

hanoii’s picture

For what it's worth, the latest patch also allows us developers to override Drupal.displayAjaxError and do whatever we want there if we want something better for any specific use case, so ++1 for this patch to be accepted. I was going to push for at least something as simple as that, but this patch does that and more, so great.

Fabianx’s picture

If someone can add the three lines of code to also check for pagehide event, I am gonna commit this :).

hanoii’s picture

+++ b/misc/drupal.js
@@ -414,6 +414,29 @@ Drupal.getSelection = function (element) {
+$(window).bind('beforeunload', function () {

isn't beforeunload pagehide' the only thing that's needed?

I can certainly submit a patch with that.

hanoii’s picture

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 341: 1232416-341.patch, failed testing.

hanoii’s picture

Status: Needs work » Needs review
Fabianx’s picture

Assigned: Unassigned » stefan.r
Status: Needs review » Reviewed & tested by the community
Issue tags: +Pending Drupal 7 commit

RTBC and marking for commit (might stay for a moment (max a few days) in that state), but pushing to Stefan for one last review.

stefan.r’s picture

Have we done manual testing on mobile Safari?

This also needs an issue summary update regarding next steps/followup issues, why we decided not to make this sitewide, and a full list of situations that are solved by this patch (reloading/navigating away while a request is in process)

ibuildit’s picture

Android lolypop 5.1 firefox and default browser gets the same AJAX error popup when reloading the page using this latest patch on latest Druapl 7 (Panopoly).

Works OK in OSX chrome, pc chrome

ibuildit’s picture

combining 1232416-341.patch with drupal_alerts_an_ajax-1232416-295.patch worked for me.

in drupal_alerts_an_ajax-1232416-295.patch I had a slight difference

mine (ajax.js) said:

Drupal.ajax.prototype.error = function (xmlhttprequest, uri, customMessage) {
Drupal.displayAjaxError(Drupal.ajaxError(xmlhttprequest, uri, customMessage));

patch said:

Drupal.ajax.prototype.error = function (xmlhttprequest, uri, customMessage) {
- Drupal.displayAjaxError(Drupal.ajaxError(xmlhttprequest, uri, customMessage)); <----- this one was different for me
+ if (Drupal.settings.ajaxErrorDisplay === "1" && window.console) {
+ console.log(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+ }
+ else {
+ alert(Drupal.ajaxError(xmlhttprequest, uri, customMessage));
+ }
+

But all good, no errors in android or elsewhere

ibuildit’s picture

I actually saw one error again when I logged out. :/

ibuildit’s picture

What is the latest, recommended, (working?) patch that supresses the error and gives us the backend setting?

What I'm using, is not working. Thanks.

Quite amazing this issue - that supressing an error takes 350 comments. :-D

Fabianx’s picture

We still need the issue summary update and follow-up issues for the UI approach, but it is kinda "waiting for commit" still from my side.

briantes’s picture

I have this error randomly when I browse drupal commerce shop (viewing products):

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /views/ajax
StatusText: error
ResponseText: 
ReadyState: 0

I have applied the patch (from #341 - two files) and the error isn't gone.
This alert box is very annoying and It causes an awful customer experience on shopping.
Some suggestion? TIA

maximpodorov’s picture

@briantes, have you visited development configuration page after applying the patch?

briantes’s picture

@maximpodorv, thanks for your help. Patchs from #341 are for js files (drupal.js, ajax.js and autocomplete.js). No new options are added on developmet configuration page. I think, that new option is the proposal solution, but not the solution itself. Or perhaps I'm wrong, but I don't see more patches. Anyway, I think the problem is Views Infinite Scroll module, but I expected this patch hide this annoying alert box.

maximpodorov’s picture

I think it was incorrect patch. The correct one adds new configuration parameter.

briantes’s picture

I have applied the latest from #341. Could you say me what should I apply?

Jaypan’s picture

The last patch I see that ties into admin pages is in #326. The other patches after that do not have any changes to PHP code.

I'm leaving it RTBC because I haven't been following the thread specifics, but I think this probably needs review.

briantes’s picture

Path #326 is for simpletest. It isn't change anything about admin pages. I have reviewed all patches files but I couldn't found what I should apply. Someone knows what patches must be applied?

annya’s picture

#341 works for me.

timfernihough’s picture

I am updating an inherited site for one of my customers currently running 7.35 to 7.50 and unfortunately they have patched core using autocomplete-1232416-17-7x.patch from comment #17. For anyone else in my situation, I have re-rolled the patch to apply to Drupal 7.50. Though, I don't expect this patch to ever make it to core. :)

UPDATE: Sorry, wrong comment number in patch by accident.

timfernihough’s picture

Properly named patch this time with real comment number this time.

lokapujya’s picture

We have a patch that was RTBC'd. If that is not the case, then can we set the issue to NEEDS WORK and post the latest patch.

hanoii’s picture

@timfernihough patch is really a re-roll from #17 that apparently he needed, but is way off the current RTBC patch, so hiding it. Please refer to the latest patch at #341 for any follow up.

hanoii’s picture

hanoii’s picture

sic’s picture

I've totally lost it. Is there a ready-to-use patch or isnt there? :/

stefan.r’s picture

@sic #341 should be OK to use, but this issue really needs an issue summary update before we commit this (see #345)

droplet’s picture

Issue tags: +Needs manual testing

If you're testing, please provide your steps also. It will help other to perform another test for edge cases. Cheers!

Jaypan’s picture

I'm at a loss as to which patch is the one that's been settled upon, and what the supposed functionality is supposed to be. Can someone put together a summary? I've looked through the last few patches, and they all seem to be somewhat all over the place, rather than appearing to be built upon each other. Questions on my end:

1) Is there supposed to be a settings page within core somewhere? And if yes, what are the options supposed to be?

2) Which errors are supposed to be shown to users, which ones are supposed to be sent to the log? What is used to differentiate between these?

3) (Maybe unnecessary) How do the options from question one affect the functionality in question two?

4) Are Simpletest tests supposed to be part of the patch?

Unfortunately we seem to have gotten entirely lost in the last page here. Lots of good ideas, but no solidly outline plan, and the issue summary seems to have not been updated to match the current goal for the patch.

Let's get together the answers to the above questions, and if anyone has anymore to suggest, and we can update the summary with a roadmap, and then put together a patch and finally get this committed. All the pieces seem to be there, they just need to be put together.

stefan.r’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: -Drupal bugfix target, -Pending Drupal 7 commit, -Needs manual testing

Discussed with @Fabianx and we are splitting out the patch from #341 into its own issue (#2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page)

stefan.r’s picture

Assigned: stefan.r » Unassigned
Jaypan’s picture

Still need to answer the questions from my last post.

hanoii’s picture

My line of thinking, and unless someone thinks differently, is that we should also create a new issue for the options page, however, I am more inclined to simple close this one as "work as designed" and when #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page gets in, creating a module that adds the options discussed in this module would be a simple task (one I can take on) so we don't bother core maintainers into reviewing/maintaining yet one more thing.

As for trying to answer your questions @Jaypan.

there are two patches here, #341which was spin off to #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page and has no ui options, it attempts to simply not show the ajax error on certain cases, namely when browsing away before the ajax finishes.

Then you have my patch of #326 which was simply an update on the previuos patches and that brings configuration option to the UI which should allow you to never display the ajax errors (or display them to console) or display them as before.

However, as I said before, with the fix on #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page, this could me moved onto a separate module.

Jaypan’s picture

Than you for some clarification. I'm still not clear of the answers on the questions I asked though. I can't examine the code, or test to see if the patches work as designed without those answers. I would imagine others are in the same position, evidenced by posts like #365,

I've totally lost it. Is there a ready-to-use patch or isnt there? :/

We need a clear outline of what is being done, before people can test to see if that is happening.

hanoii’s picture

@Jaypan Honestly, I do think I answered your questions, but anyway, this is what I am talking about:

https://www.drupal.org/sandbox/hanoii/2810177

I will likely promote it, but by applying #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page and installing that module, you will have pretty much everything that was suggested in this issue.

Jaypan’s picture

This shouldn't be a module, it should be part of core. People have been pushing for this for years, and adding the overhead of an additional module to fix a core bug is not the right way to go. Core bugs should be fixed in core.

The problem is, I can't test any of these patches, nor even create a new one, because there is no specific outline of what is supposed to happen with this patch. When is the console supposed to be written to? When is the alert supposed to happen? What differentiates them?

hanoii’s picture

Well, I disagree, but hey.. that just me.

The problem is, I can't test any of these patches, nor even create a new one, because there is no specific outline of what is supposed to happen with this patch. When is the console supposed to be written to? When is the alert supposed to happen? What differentiates them?

Although I think this was clear in the previous posts and even in issue summary, here is another attempt:

- Currently, whenever an AJAX call fails, Drupal shows a javascript alert to every user. Ajax calls can fail for many many reasons, timeout, network issue, server not responding, wrong url, page not found, etc.
- These alerts, regardless of whether it's a true error or not, are a bit technical, so not very user friendly.
- This issue emphasize in cases like for example, if you are doing an AJAX call (autcomplete or whatever) and click on a link of the site, the Ajax call is cancelled and the error is shown, this is really not an "error" as you personally triggered it.
- Patch on #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page is simple, it keeps the exact same behavior as now (show an alert on AJAX error) except if it happens after an beforeunload event. For further explanation on this, please go to that issue.
- How to test that is well explained by @David_Rothstein at #336, there's even a patch to easily test it.

So far, console has nothing to do with anything.

- Patch on #326 adds a setting to the "Logging and Error" that allows you to configure wether to show the alert at all or instead log it to console. This is mainly because these errors, even when they are legit, are not very useful to the customer. Again, what https://www.drupal.org/sandbox/hanoii/2810177 attempts to do.

Anyway, I think pushing something like that into core, is going to be a bit of a pain. And the purpose of modules are to extend core to cover more use cases the general ones. It's simpler to maintain a module than core, and feature-wise a module can get a lot further than core. So as long as there's any point of extendability, I am good with how core is.

As it is now, there's no patch here to test, want to test something out you can do it with the patch on #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page, although it's already RTBC, so that one will likely go in very soon.

What this issue needs, is probably a better summary, and to be spun out to another one so it can start afresh, with a clear picture of how far core maintainers are willing to take all of our preferences and it would make sense to pursue that once the other one gets in.

hanoii’s picture

Status: Needs review » Needs work

Mostly setting it to needs work until there's a definition on what we do with this issue.

droplet’s picture

No UIs, No Logging.

Unless I'm missed something, I don't see any point to provide a logger (either backend or console.log) at this case. The annoying Alert showed because we made a mistake with bad code design there. #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page or my patch #282 are trying to mute it without broken the BC layer I think. If not, we should look forward to matching D8 behavior.

All patches with UI or console.log are trying to mute it for DEVELOPERS. It seems not right to me. In fact, if we providing any development toggle, it's better to make it global: https://www.drupal.org/node/1639012#comment-10136758

`Drupal.displayAjaxError` is a public API. Hacking it for your needs. Or submitting a patch to Devel?

  • stefan.r committed a3532b6 on 7.x
    Issue #1232416 by hanoii, nod_, heddn, geerlingguy, lokapujya,...

  • stefan.r committed 1f6920c on 7.x
    Revert "Issue #1232416 by hanoii, nod_, heddn, geerlingguy, lokapujya,...
Jaypan’s picture

Well, it looks like this issue has been committed, so the initial problem listed in the thread title has been committed.

stefan.r’s picture

@Jaypan just to clarify, #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page was committed, not this issue -- the commit message accidentally included the issue number for this issue (hence the revert)

Rajab Natshah’s picture

+1 .. I'm with this feature.
Testing .....

nod_’s picture

Status: Needs work » Fixed

This issue is too many comments long. The original issue: "Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors" has been fixed in #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page.

Now for any other feature request, or discussion it needs to happen in #1419652: JavaScript logging and error reporting.

Providing a new UI means new strings, new translation work and so on. It is way too late to introduce a new feature for this in D7 core.

stefan.r’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update

Updating the issue summary with the comment in #385.

Providing a new UI means new strings, new translation work and so on. It is way too late to introduce a new feature for this in D7 core.

I'm not opposed to such new features necessarily -- with #2598382: [policy] Adopt a 6-month feature release schedule for Drupal 7 (similar to Drupal 8) and use pseudo-semantic versioning we can introduce new features in D7 for problems that have already been solved in D8.

hanoii’s picture

Issue summary: View changes

Also noting that I just promoted https://www.drupal.org/project/ajax_error_behavior, which moves some of the features/ideas requested here into a module, feel free to try/contribute to it.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

karthid’s picture

In My Case.

I got error Like this in my mysql_error.log file: The total blob data length (XXXXXXX) is greater than 10% of the total redo log size.

I increased the value of the innodb_log_file_size option in my.ini as below and its fixed.
innodb_log_file_size=256M

Be careful when changing the value of innodb_log_file_size that you do this safely

Note: Please check your mysql_error.log file before changing it.

guddo’s picture

This is still not sufficient for the latest Drupal core release (7.53).
The attached patched solves the issue.

SebaZ’s picture

I think it's a problem with X-Frame-Options as I mentioned there
https://www.drupal.org/node/2876109#comment-12230334

mattwmc’s picture

Awesome. Thanks, guddo.

skgk’s picture

An ajax http request terminated abnormally.
Debugging information follows.
path:/en/system/ajax
StatusText:error,
ResponseText:
Readystate:0

This is my drupal7 error. It is thrown after i defined domain redirection to another domain in .htaccess file

aitala’s picture

Any idea if this is still an issue in D 7.57?

E

SKAUGHT’s picture

see #384

seem that this issue was superseded by another. maybe a new related issue to re-handle the concern?

sic’s picture

Why is this still not in the current d7 stable version?

xurizaemon’s picture

See comment 384 above I think, marked fixed there.

Suggest opening a new issue (if not already addressed in #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page or #1419652: JavaScript logging and error reporting).

It's fine to resubmit patch from this issue to some other open issue if that helps.

xurizaemon’s picture

Aambro’s picture

I have successfully managed to hide pop-up for ajax error, but actually I'd like ajax to keep running or retrying calls when error happens. I am using views auto-refresh and the site needs refreshing in case there's been a short temporary loss of internet connection (for example mobile operator switching, switching between mobile data and WiFi). Now i have to manually refresh the site every time an error happens. If this issue fits in new issue opening, please suggest alternate segment where to post it.

sic’s picture

This error actually still occurs. Also, I dont have the AJAX console log option in settings, was this discarded? Running the latest D7 version.

hadsie’s picture

I've created a new related issue to this (and a patch) https://www.drupal.org/project/drupal/issues/3039666.

I don't think the patch in comment #389 is right, as it will ignore some errors that should be triggered. Hopefully the patch in #3039666 will solve the rest of the problems that people are having with these errors.

Bruno Vincent’s picture

Same for me from post #399

"This error actually still occurs. Also, I dont have the AJAX console log option in settings, was this discarded? Running the latest D7 version."