HTTP vs HTTPS change in behavior using WebMapTileServiceImageryProvider in latest cesium release

1. A concise explanation of the problem you're experiencing.
It looks like the way Cesium handles tiles from HTTP locations has changed in version 1.56.1.

In 1.55 and before, if you tried to serve https content over http, you'd get a "mixed content warning" but it would still work.

In 1.56.1, you receive an error regarding the mixed content, but the tiles will no longer be displayed.
You'll also see a new error in the console:
"An error occurred in "WebMapTileServiceImageryProvider": Failed to obtain image tile X: # Y: # Z: # Level: #" (where # is replaced by actual numbers)

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

If you paste the first example from the WebMapTileServiceImageryProvider documentation into a cesium sandcastle from 1.55, it works fine. If you paste it into Cesium sandcastle for the current version (1.56.1), you receive the above errors and don't see the shaded relief basemap.

doc link

Alternatively, you can just run these sandcastle examples:

1.56.1 (errors in console)

1.55 (works fine)

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

We're serving some basemaps over as HTTP. It worked in previous cesium releases (throwing a warning in the console about mixed content), but in the most recent cesium release we can no longer see our basemaps due to the aforementioned error.
Did something about the way mixed content is handled change in cesium 1.56.1?

4. The Cesium version you're using, your operating system and browser.
Cesium 1.56.1 vs version 1.55, Windows, Chrome

We did change the way images are fetched to use createImageBitmap for faster image decode when browser support is available. You can override this check to force the order behavior by adding this before initializing the viewer:

Cesium.Resource.supportsImageBitmapOptions = function(){
return Cesium.when.resolve(false);


Let me know if this fixes the issue in your app. I'll investigate this more to see why this new code-path is failing in this case. Thanks for letting us know!

Hi Omar,
Thanks for the response. The code you posted fixes the issue in our app.

However, are we missing out on anything by doing this? You mentioned "faster image decode"; if, instead of using the code you posted, we switched to HTTPS would we see performance improvements?

Also if this is unintended behavior, do you have a link to a github issue I could follow? I can also create one if that helps.


If you’re loading very large images, you might encounter some frame stutters during load, and createImageBitmap should help with that. You can read more about it in the pull request here:

If your images are relatively small (smaller than 500x500 perhaps) then I don’t think it will have a significant impact.

I did open a GitHub issue with some thoughts on where I think the issue is:

Feel free to chime in there or if you’re able to find any more information debugging it, that’d be greatly appreciated!