Cesium not requesting createGeometry when accessed locally?

1. A concise explanation of the problem you're experiencing.

I'm using Cesium in a local application. When Chrome accesses Cesium 1.25+ on-disk (cross-origin security disabled of course), no entities will display. No errors appear on the console, instead the createGeometry worker is never requested. So far I've traced the cause to EntityCluster.prototype.update(), where none of the branches will evaluate to true.

2. A minimal code example. If you've found a bug, this helps us reproduce and repair it.

Add a Wyoming entity to the HelloWorld app, then access the app's index.html with Google Chrome using the flags --disable-web-security --user-data-dir=/usr/USER/chrome/devprofile

3. Context. Why do you need to do this? We might know a better way to accomplish your goal.

Attempting to use Cesium in local application that renders HTML5 GUIs with Chromium.

4. The Cesium version you're using, your operating system and browser.

Cesium 1.25 - 1.37 exhibit the bug, but Cesium 1.24 (and previous) successfully request createGeometry. Using the Chrome 60.0.3112.90 browser on Windows 7 and RHEL7.


I previously misidentified the issue as Browserify-caused, sorry about that. Feel free to close that previous thread.

Hi Christopher,

Thanks for investigating this! Try this flag additionally to make sure you can load local data.


If that doesn’t work, I’ll open an issue in the repo.



I believe I tried that flag before, but I attempted it again just to make sure – unfortunately, createGeometry still isn’t requested.

On Behalf Of Gabby Getz

Ok, so I determined the exact issue. When using Cesium locally, "approximateTerrainHeights.json" silently fails to load, which means the GroundPrimitive never initializes, and the DataSourceDisplay can never update, so entities are never converted into displayed primitives.

"approximateTerrainHeights.json" fails to load because loadWithXhr expects a valid HTTP response code, which is a slight problem when loading the file from disk. It sees a status of zero and thinks it's an HTTP error. But the file was actually resolved (which is why the error is silent), and when I modify the code to allow a zero-status everything starts working again!

Obviously you don't want to accept a HTTP status of zero for actual web requests. But we can simply filter by the requested URL and accept a zero HTTP status if the requested URL startsWith("file://"). I can start a small pull request to this effect.

Hi Christopher,

Sorry I was slow to respond so I wasn’t able to let you know before you open your PR.

So this issue of using the file protocol with Cesium has come up before, see discussion in Issue #5326 and Issue #3935

Instead of this change, we’d recommend using something like Electron to run your app. See our blog post on getting that set up here: https://cesium.com/blog/2016/04/04/an-introduction-to-cesium-desktop-apps-with-electron/

Thanks, hope that helps,


I appreciate the advice & have seen that tutorial. But I am already using an unsandboxed Chromium tool similar to Electron. In both issues that you linked, @mramato's comments assert that Cesium should work with the file:// protocol without the security sandbox. However, this issue prevents the protocol from working as such.

The PR is a small, contained fix, so I highly doubt it would introduce maintenance issues down the road.

Ok, I see your point. I’m trying to reopen the PR, and we have added a suggestion there as well. You should be able to make the changes to your branch and push in the meantime.

Thanks, sorry for the turnover.

If you’re still having this issue, try out:

We had the same issues, thus the package.


TJ, the issue with running Cesium locally was solved, merged, and appears ready for Cesium 1.39!

Awesome!! One step closer to replacing GE for good…