Ajax errors are not communicated through the UI

Running Drupal\Tests\system\FunctionalJavascript\OffCanvasTest::testNarrowWidth locally I also see a failure.

core/themes/olivero/js/messages.js is trying to write to Drupal.olivero
core/themes/olivero/js/navigation-utils.js defines Drupal.olivero

and they are running in that order!
I'm not sure the best way to get them in the correct order.

I love that this surfaced and fixed a bug!

I'd mark it RTBC, but #10 is not addressed as this is not yet configurable. Is that still needed first?

tim.plunkett → credited bnjmnm → .

Oh lol, Nightwatch tests are still failing. Glad I didn't RTBC :D

Reviewing MR 3609

Left a comment but why wouldn't olivero/global-styling not be there?

Also I see the new ajax_test routes but don't see the test that calls them? Unless there's something that loops through all the routes? But couldn't find that.

Also to echo what tim.plunkett said. This sounds like a great feature to get included!

The test routes were added in #4 but only for manual testing. You're right that we need an automated test to use them. Leaving the other response on the MR.

Discussed with @ckrina who is one of the Usability topic maintainers. We agreed that this is a net-win as in all situations where user is triggering an action, and it fails to execute. Adding new error messages may make us discover some bugs in other systems but that's not the fault of the error, in fact it's the opposite since it will help us expose those use cases and work on the root cause.

Quoting an article from Nielsen Norman:

Good error message should include:

Explicit indication that something has gone wrong. The very worst error messages are those that don't exist. When users make mistakes and get no feedback, they're completely lost.

Human-readable language, instead of obscure codes or abbreviations such as "an error of type 2 has occurred."

Based on this, it would be great if we could still iterate on the specific wording of the message. I think we should at least try to remove mention of ajax since it's not language that users are accustomed to.

Moving to NW per #32.

Leaving the needs tests tag incase any additional coverage is needed.

An AJAX system error has occurred. -> Oops, something went wrong. Check the console for more details.

Updated message string to remove the mention of AJAX and point to the console if the user wants more information.

Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTest::testButton
Failed asserting that a NULL is not empty.

I got this failure once in every 10 local test runs.

I think this is described here as well #3346122-4: ckeditor test failures causing pain for unrelated patches →

Tests were added in
b1f1df3b - WIP: add test that currently fails

Get the same results as #34 using the new routes provided.

Points from #32 appear to be addressed.

Think

it would be great if we could still iterate on the specific wording of the message

could be a follow up?

+1 for RTBC, the wording changed in the last commit and I think it's shippable as-is

I agree with #37, the wording is now less technical. Looks great.

Hm, the problem statement is this:

Currently ajax errors are only visible in the browser console. This is confusing for non-technical users because there's no indication in the UI that an error happened.

Looking at the error message proposed, I think "the console" would not be evident to a non-technical user. Is it a Drupal backend concept or in their command line terminal? I think "your browser's developer console" or something along those lines would be easier to google for. It would be nice if there would be a product agnostic page that we could link to, like https://balsamiq.com/support/faqs/browserconsole/ but not under Balsamiq (nothing against Balsamiq but you get the idea). Otherwise I think "your browser's developer console" makes it much more specific and is good basis to google for. I am not attached to these specific words, but IMHO "the console" is not enough for a non-technical user.

Rishabh Vishwakarma → made their first commit to this issue’s fork.

Confirmed the message is now

Oops, something went wrong. Check your browser's developer console for more details.

It looks like there was a decision to make this configurable, which I don't see in the MR. Either that should be added, or someone can point out where that requirement changed and switch this back to RTBC.

Reading it back, I realize that #32 may have been unclear. The reason I made that comment was to try to make a point that we shouldn't make it configurable because having these error messages are essential for UX. I discussed that with @ckrina as well to make sure that she didn't have concerns on that.

I agree that this is a step in the right direction.

I am concerned that the message is not helpful to a non technical user because it suggests that they learn how to use a technical tool. And they will need to search for how to do that for their browser. Instead can we change this to a message that they should contact the site admin?

Refining that message content could potentially delay what is a very helpful improvement. I created a followup to focus on adjusting that language after this lands, which lets this feature get in while still providing us with a place to potentially improve that messaging.

📌 Determine if there is a better message for AJAX errors. Active

Created and published a CR for this.

Committed e492ae3 and pushed to 10.1.x. Thanks!

lauriii → closed merge request !3609

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

So I think this issue broke Javascript messages on batch forms. But there were no tests for that so it wasn't going to be caught.

Created 🐛 Exceptions in batch no longer are shown on the page when Javascript is disabled Needs work we have a test there and are working on a fix. Any help would be appreciated.

Hi,

I might be in the wrong here, but why assuming that every Ajax response should return a 200 is the expected behavior for all websites.
Sometimes you might want your user to be able to click an ajax link which will return a 403 for example. Then you purposely display a message to your user that they are not allowed to perform the action.

With this addition, websites have now a non-needed, non-user-friendly message displayed to users on expected 403.

Maybe a good addition would be to make this feature optional (as per improving the message in 📌 Determine if there is a better message for AJAX errors. Active )?

It makes AJAX error behaviors more configurable.