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.
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.
