That would be useful only to like 0.0001% of all users.

As a normal user, I experienced the same problem on Spotify while trying to pay my monthly subscription. There were JS errors and XHR request failures after the user interaction that Spotify don't aware of it. It can be a serious process too. For example, urgently transferring money but some of the components don't respond on the bank's website. It could be useful for developers too because users will able to report the web app related bugs to them directly. I believe it is not 0.0001%.

rufatmdl@ Thanks for the issue.

Marking this as Untriaged as this is a feature request for JavaScript/XHR Failure Indicator on Address Bar.
Request Dev to look into this and help in further triaging.

Thanks..

I think this kind of thing falls under the "Security Indicators" tag.  Marking appropriately.

Thanks for the request. In what way would exposing details about JavaScript or XHR errors be less confusing for users? I would expect the very vast majority of Chrome's users to be more confused, since XHR and JavaScript are details of the web which are not widely understood outside of the developer community (which, while large, is definitely not the majority of users).

Technically savvy users and developers who really want these details can use the Developer Tools console (right click -> Inspect, select Console tab) to see any and all JavaScript errors, and use that as a basis for giving feedback. This is the correct place for these errors - within the tools which developers are already encouraged to use.

Thank you for the response. The indicator should just inform the user about the web app might not work as expected. And then it can redirect the user to devTools or report the issue directly to web app owner (bundled with console logs). The web app should have a meta tag with a webmaster's contact e-mail.

In reality, there are many reasons that requests could fail (ad blocker, poor connection, developer error, etc.), but there is no guarantee that the site won't work due to a failed request. Iindeed, most sites still work even when requests for ads and the like are blocked (just open the console and browser around and see how many failed requests pile up in the console log.

Saying that the site might not work as expected is a poor experience because users would see this piece of UI *very often*, and it would often be incorrect, since a failed request is not indicative of the site not working. Additionally, the vast majority of users are not going to know what to do if DevTools is opened.

If the developer wishes to add contact information in a meta tag, they could instead change their site to actually detect and be robust to failed requests, and display their own UI that the site may be broken.

As I mentioned before the indicator must work only after the user interaction and should only detect the same domain name API endpoints.

Sometimes these failures are happening because of cache related issues without aware of developers (ex: Spotify (happened to me)).

But, I agree, this is not an urgent feature.

Thank you.