There are several aspects of this.

  1. #1606362: Use throw when an ajax error occurs and extend JavaScript's Error object
  2. AJAX error reporting is too obnoxious #1232416: Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors,
  3. #77245: Provide a common API for displaying JavaScript messages, [blocking]
  4. #505598: Convert alert() to ui.dialog,
  5. #1419648: javascript error reporting interface have a Drupal log function that follows error reporting levels,
  6. #1206974: Add a window.onerror JavaScript handler,
  7. #727278: Add watchdog interface for javascript code to use.

We need to decide:

  1. What to expose: watchdog interface, javascript logger (it could use watchdog too), change alert to dialog;
  2. If something like firebug-lite should be available for browsers without a console to allow easy debugging,
  3. specific error level reporting for JS,
  4. maybe something I forgot.

Let's talk about this.


nod_’s picture

Issue summary: View changes


nod_’s picture

Issue summary: View changes

one issue per problem.

rfay’s picture

Just want to say thank you for all your activism on this!

peterx’s picture

Add an email interface so you can send messages.

nod_’s picture

That's not a bad idea in itself, unfortunately it has nothing to do with javascript :)

peterx’s picture

When you are creating a Javascript based application, you sometimes need to send messages. Most of those messages are watchdog style logging of events. I wrote jDog to do that. Some of the critical errors need immediate attention and an email is better. I added email to jDog because one site needed immediate alerts for some problems occurring in jQuery code. Their use case is mixing several jQuery based functions on one page and reporting the occasional clash. If the second or third section of their jQuery cannot proceed, send email to the jQuery developer or the content administrator.

In the current jDog approach, you can add an email to a severity level. The test case sends email for errors, not warnings. There is also allowance for an email to anyone for any special cases.

The email is sent to the Web site using the same Ajax as the watchdog. The Ajax callback code sends the email from within Drupal. The email use case is similar to the watchdog use case and lets you send an immediate alert. The watchdog Javascript code requires only one extra parameter for email.

The same Javascript code could be extended to SMS, bleets, anything you need for message alerts, by extending the PHP code to decode the address for something other than email.

Other use cases suggested to me include alerts for problems with multipage forms and unusual choices in games. The developer can react immediately to unusual results in their Javascript. The only current alternative is to spend all day looking through the watchdog log.

nod_’s picture

I think that'd be more of a watchdog extension, or even a Rules thing. I don't think it should be JS-specific, after all, you might want to have a mail if the watchdog logs hundreds of times a 404 on some image too.

It's a more global issue than just JS errors.

apotek’s picture

General comment on JS error logging/mailing. Since a user can use any JS based logging facility, we are potentially opening up a security hole. I certainly don't want arbitrary JS errors postable (via a service) to watchdog or to sendmail.

Some errors can simply be ignored (autocomplete comes to mind). The main thing is to simply never expose any dangerous diagnostic information to the user in an ajax reply from the server, unless display errors is enabled.

Other, more serious errors, can be displayed to the user with a softer, more general (themable?) error message in an alert dialog or jquery-ui dialog, with diagnostic information sent to the console.log, IF the site has been configured to display errors. My $0.02.

peterx’s picture

Re security. The JS sends stuff to a URL. The URL starts PHP code and the PHP code passes stuff to watchdog and mail. The PHP code is responsible for cleaning stuff.

Watchdog cleans all variables prior to substitutions. That leaves only the message variable to be cleaned by the PHP code.

Mail does nothing to keep things clean. The PHP code has to clean everything for mail.

jDog is loaded at and is running on several sites where the content is cleaned before passing it to jDog. The cleaning of variables in PHP is not yet systematically tested. If someone wants to perform a security check, I can update the code.

I am happy to pass this module to someone who wants to be a Drupal contributor and needs a starting project, sort of like a Google Summer of Code project with all the glory but not the money. if the person is in Sydney, Australia, I can mentor them in real time.

peterx’s picture

Issue summary: View changes

clean up list

Bevan’s picture

JS Watchdog module may serve as a discussion point or prototype for this issue.

nod_’s picture

nod_’s picture

Issue summary: View changes


corbacho’s picture

Issue summary: View changes
mgifford’s picture

mgifford’s picture

Version: 8.0.x-dev » 8.2.x-dev
geerlingguy’s picture

Issue summary: View changes
droplet’s picture

Message in Frontend for vistors VS Logging to backend for developers

It's 2 very different concepts.

A simple JS logging may not help for debugging. Some free / paid / open source tools/services with a powerful panel will do a better job ( for both debugging & logging performance ).

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nod_’s picture

Title: [Meta] javascript logging and error reporting » JavaScript logging and error reporting
Category: Task » Plan
hanoii’s picture

For what it's worth, now that #2808789: Fix "An AJAX HTTP request terminated abnormally" alert after user has navigated away from the page is in, I submitted which could serve as an alternative while a decision is made here.

Maybe useful to add it to the summary, although not sure if it belongs there.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.