Why are there so many 404 errors in the browser dev tools console?

Why are there so many 404 errors in the browser dev tools console?

This is due to the way web browsers log things “that happened” and for whatever reason, browsers have decided that all 404 responses from any server are labelled as “error events”. This of course is not the reality of the situation. Not all 404 responses are actually application errors, just like not all 200 responses are successful application outputs.

 

all Ultimate Dashboard for Jira gadgets are entirely “client side” and do not communicate with any of our web services, they all use Jira’s REST and JavaScript APIs directly and as such all the stuff that would have happened on the Ultimate Dashboard for Jira server-side happens instead within the browser viewing the dashboard gadgets - doing this protects your data with the highest level of security we can provide while still providing ultimately useful dashboard gadgets

 

Take the following examples:

 

  1. When a gadget is first added to a dashboard:

    • the gadget has no idea if there are any settings yet because all settings are stored as dashboard item properties with Jira’s REST API

    • so the gadget must ask Jira:

      • “hey there, is there a dashboard item property with our user’s settings in it?”

      • to which Jira replies “nope!”

      • the way Jira says that “nope” is in the form of a 404 response to the gadget’s request for data

        • and the user’s browser logs an XHR 404 error, because all 404s are errors right?

    • so then the gadget knows to:

      • present the user with the configuration panel so that the user can supply the settings which the gadget then stores on the Jira dashboard as an item property

      • Jira responds to that XHR request with a 200 status

    • the next time the dashboard/gadget is reloaded, the gadget (being entirely client-side) has no idea if there’s any settings and proceeds to ask Jira:

      • “hey there, is there a dashboard item property with our user’s settings in it?”

      • to which Jira replies “yep! here you go!”

      • and the way Jira says that “yep” is in the form of a 200 response with the user’s settings as data in that response

  2. When the controller gadget starts up:

    • the gadget has no idea…

      • … if there are any boards present that have sprints the controller can present as settings to the dashboard users

      • … how many projects there are

      • … what filters are available to the current user

    • and so the gadget needs to ask Jira for all this information

    • which of course sometimes results in 400 errors because some boards can’t even have sprints and so one

    • and the browser logs all of these 400s and 404s to the dev tool console

    • and users get curious as to what’s happening

    • and eventually they find this page of helpful context

    • and realize, this is actually very secure and really neat!

    • “I didn’t know that the internet works this way!”