Search code examples
google-chromesapui5localdevelopment-environment

Bootstrapping SAPUI5 App Locally Throws Error after Upgrading UI5 Resources to 1.54

The local SAPUI5 applications do not work with 1.54.xxx anymore. They work fine with 1.52.xxx.

By "local SAPUI5 applications" I mean applications:

  • loaded from local drive without http server
  • using CDN
  • using browser with disabled SOP like Chrome with --disable-web-security --user-data-dir

Such application work fine with 1.52.xxx:

src="https://openui5.hana.ondemand.com/1.52.11/resources/sap-ui-core.js"

but dumps with error from ui5loader-dbg.js with 1.54.xxx:

src="https://openui5.hana.ondemand.com/1.54.4/resources/sap-ui-core.js"

The errors occurs during loading of Components.js or controllers, samples from two programms:

ui5loader-dbg.js:882 Uncaught Error: failed to load 'zprog/Component.js' from ./Component.js
ui5loader-dbg.js:882 Uncaught Error: failed to load 'ztest2/controller/App.controller.js' from ./controller/App.controller.js: 0 -

Do you know the reason of it and have an idea how to run local SAPUI5 application with 1.54?

Solution

  • I believe the main cause is the browser not supporting asynchronous XHRs for local files (file://) as mentioned in MDN:

    Some browsers (including Chrome) will not run async requests (see Fetching data from the server) if you just run the example from a local file. This is because of security restrictions (for more on web security, read Website security).

    As UI5 gradually moves towards asynchronicity (#UI5Evo) and due to the security reasons, developing applications with the file:// protocol should be avoided.

    Instead, try to setup a local HTTP server for which many tools are out there, such as Web Server for Chrome. Running the app on the server also allows the browser to respect CORS (No need to turn web-security off).

    Discouraged Approach

    Despite the framework not supporting the file:// protocol, relying on unsupported and buggy command-line flag, ignoring security standards, and being uncertain about whether the workaround might still work in the future or not, you can still make the app run with the version 1.54 if all requests are made asynchronous. For example:

    • Given:
      • Chrome's command line flag
        • --disable-web-security --user-data-dir
        • Or --allow-file-access-from-files
      • UI5 sample application provided on the equivalent GitHub issue
    • Before loading the sap-ui-core.js file, activate the hidden experimental flag xx-async.
      • <script>
  window["sap-ui-config"] = {
    "xx-async": true
  }
</script>

    • And load everything else asynchronously as usual, such as providing async: true when creating ComponentContainer or root view.
      • Workaround working

    Update (2018/05/10)

    Just yesterday, there was a new commit that shed more light on why it didn't work after upgrading to 1.54 and why the workaround above had to make use of async XHRs everywhere.

    With 1.54, a new internal file ui5loader.js was introduced. Besides many cool features it brought, it also took mostly the code from jquery.sap.global.js away that handled loading modules. While migrating, a fallback to sync XHR had to be implemented for the case when legacy sync APIs are used. That was realized with the function loadSyncXHR.

    In that loadSyncXHR function, the module was considered loaded when the returning XHR status was 200. However, as the new commit suggests, some browsers, including Chrome, return the status 0 when the file was loaded from a file:// protocol. That check was missing until yesterday, so it had to be added.

    if ( xhr.status === 200 || xhr.status === 0)

    If you run the same project with src="https://openui5nightly.hana.ondemand.com/..." without changing the code, the errors shouldn't be thrown anymore.