DOMException: A network error occurred

Hi guys, I’m trying to run an app on WebOS v.4.4.0 with es6 and I’m getting this error from the inspector DOMException: A network error occurred.
Does anyone have any idea that can help me?

A network error typically happens when you’re trying to do an XMLHttpRequest or other network request that fails.

For more information:

NetworkError is listed down below in the possible events.

Can you pin point where the error happens in your app? Are there any network errors that occur when you run it on your dev environment?

I personally like Making HTTP/Web Requests in JavaScript as a generic networking & javascript resource :slight_smile:

The app does not crash in development environment or simulator, but when I run it on a real device it does, and it crashes as soon as it starts, I am only accessing image urls since I have the data in a local json file.

Check to make sure its not a CORS issue. If you’re loading the images from a separate URL from your web app, it may cause a network error - but I assume you’d get the same issue in dev environment.

Also maybe try turning off the useImageWorker

Hi @Wouter, Do you have an example of how to make the requests inside lightning to access the resources? we have exhausted all the solutions we had in mind and we are still getting the error.

You can check out the example app here:

That makes AJAX requests and loads images from TMDB.

Hello @chiefcll and @Wouter and thanks for stepping into this problem and share your ideas on how to approach to it.

Tatiana (Post Author) and I work together, and after some trial and error we discovered what the problem seems to be. It looks like the fontLoader default method that Lightning is using to load fonts, is missing some exception control for when there’s any error trying to load font resources, for example: an static file that does not exist or, an unavailable remote font file.

Please have a look a this Plunker:, where I put some minor changes in the basic lightning app to illustrate the situation.

In line 6378 of /js/appBundle.js you’ll find some fonts being added to the project, some of them are clearly mistakes, while there’s just one valid case. Now, in line 2895 of the same file, you’ll find the fontLoader method and the callback function for the reduce action when walking the fonts array; I added a catch statement to the promise being returned, which seems to control the exception generated when trying to load an invalid font and also avoids crashing the application. If you comment/remove that catch, the application will try to load the fonts, but it’ll crash with the DOMException we initially described in this post at the first error. If you leave the catch, the app will try to load the fonts, catch and log any error, but it’ll continue loading the application with the system default fonts as fallback.

I am not sure if you have experienced this issue before, but in any case it looks like controlling a possible exception there, is necessary to solve possible problems like:

  • Remote server where fonts are hosted is down
  • Remote font file cannot be accessed
  • Remote font file does not exist
  • Local font file name could be wrong
  • Local font file does not exist

Please let us know your thoughts on this, and don’t hesitate to ask for more information :slight_smile:

Thanks in advance!

  • Nicolas

hey @nlopezl , you’re referring to adding a catch to this line, right? Lightning-SDK/index.js at master · rdkcentral/Lightning-SDK · GitHub

That would make sense I guess, and seems like an oversight on our end when we created the font loading functionality

Hey @michiel , yeah, that’s correct, is where the exception is thrown.

Another question comes to my mind. From what I see in the file (Lightning-SDK/index.js at master · rdkcentral/Lightning-SDK · GitHub), looks like it is possible to add a “custom” fontLoader using the platform settings, is that right? If so, where should this custom method be defined in the source code?

I’m thinking we can copy and adjust your current fontLoader method to avoid “hacking” the SDK. What do you think?