Sandcastle CSS broken on Firefox v140

[mzschwartz5]

What happened?

On the latest version of Firefox (140 as of writing), Sandcastle's CSS appears to be broken:

Firefox v139 and Chrome do not exhibit this issue.

@jjspace found that changing the import URL of the bucket.css file from:

@import url(../templates/bucket.css);
to
@import url("../templates/bucket.css"); (quotes added)

fixes the issue on Firefox v140. He also noted that the MDN spec says quotations are optional, so this could be a bug in Firefox. However, it seems that this bug is not reproducible in a minimal example app, so something else in Sandcastle may be contributing.

Reproduction steps

1. Run Sandcastle in Firefox v140 (locally or via sandcastle.cesium.com)
2. Observe the bad layout. Compare to Chrome or Firefox v139.
3. To observe "fix," add quotes to the bucket.css import URL in one of the sandcastle gallerly html files and serve locally.

Sandcastle example

No response

Environment

Browser: Firefox v144
CesiumJS Version: 1.130.1
Operating System: MacOS Sequoia 15.5 M4 Pro

[jjspace]

found that changing the import URL of the bucket.css file from:... quotes added

Interestingly changing it to @import url(..\/templates\/bucket.css); also works. I don't know why yet though. I'm more suspicious again that it's not on Firefox's side but instead on our processing of the code value or the way we're passing it into the iframe.

Edit: Even just adding spaces around it makes it work... 😕 @import url(../templates/bucket.css );

I tried to create a minimal reproduction but wasn't able to thus far...

(It definitely doesn't help debugging that CSS imports do not show in the network tab)

[jjspace]

Ok, now I'm mega confused. It seems like it's something about the extremely specific format of the style/import tag that's there by default. When changing anything about the style block it works as expected (see video). But setting it back to the default form it doesn't work. It also doesn't work with the sandcastles that add extra styles like the 3D Models Coloring one. However, again, when changing the style tag at all it starts to work again... 😞

simplescreenrecorder-2025-06-27_17.27.39.mp4

I'm gonna sit on this over the weekend and see if my subconcious can think of any reasons this might be but if anyone else feels like trying to take a stab at it please do! 🙏 The most relevant code is here:

cesium/Apps/Sandcastle/CesiumSandcastle.js

Lines 620 to 622 in 5435b95

	const htmlElement = bucketDoc.createElement("div");
	htmlElement.innerHTML = htmlEditor.getValue();
	bucketDoc.body.appendChild(htmlElement);

This is the minimal sample app I was trying to test with but it "just works" as expected. Just run npx http-server at the root after unzipping.
test-ff-bug.zip

[javagl]

No solution for this from my side. But I'd be really suprised if this wasn't a deeeeeply intricate issue of FireFox itself.

From the symptoms (that you already described), it seems like the lines

htmlElement.innerHTML = htmlEditor.getValue(); 
bucketDoc.body.appendChild(htmlElement); 

are behaving differently in the case that "works" and the case that "doesn't work".

The specific difference (still high-level): In the case that works, it is fetching the bucket.css, and in the other case, it simply doesn't (leaving the whole style below that empty). I tried to zoom into the differences:

Left is the case that does not work. Right is the case that does work. In the right case, there's that "CSS Parsing" below the appendChild, which isn't there in the left case. But ... what that means, exactly, is not clear.

I first though that there might be something in the context of https://bugzilla.mozilla.org/show_bug.cgi?id=1941347 that caused an undesired side-effect. This was released in version 140 via https://bugzilla.mozilla.org/show_bug.cgi?id=1962084 ). But 1. there are no such attributes in the HTML that we have here and 2. manually switching this feature off didn't make any difference.

Apparently, the issue is caused only by the <style>-part. Inserting a space before a <div> does it not make go away. Inserting a before the closing </style> does make it go away. So this may be related to ~"some 'style' parsing functionality". And I also tried to zoom into some bug reports/commits, to see whether anything stands out - there certainly are many changes related to style, CSS parsing, and caching, but without being one of the maintainers, one could only make guesses here....

However, the bottom line (literally):

Whatever this is: It should not be affected by a single, meaningless space character in the innerHTML.

[ggetz]

Discussed offline:

• @jjspace will implement a "hacky" fix by including the additional space so we can get this fixed for tomorrow's release.
• He'll also open an issue for this directly with Firefox.

[jjspace]

Documenting some other things I've done to investigate

Logging the stylesheets:
I found modifying the embedInSandcastleTemplate function in Sandcastle-helpers.js and adding these lines to log the stylesheet rules helpful in verifying that the imported rules are only fetched and built under certain circumstances

      `    Sandcastle.finishedLoading();\n` +
      `console.log(document.body.innerHTML);\n` +
      "const importRule = [...document.styleSheets].find(sheet => sheet.rules?.[0] instanceof CSSImportRule);\n" +
      `console.log(importRule?.cssRules);\n` +
      `console.log(importRule?.cssRules?.[0]?.styleSheet?.cssRules);\n` +

This fact, paired with what @javagl found above really points me to this being an extremely niche bug in the way FF is processing CSS rules. The sheet is being created with the correct CSSImportRule object pointing at ../templates/bucket.css regardless of the extra spaces or using quotes "" or not. However sometimes it's not actually populated with rules.

I also modified the standalone.html file directly to try and create a more minimial reproduction. Change the initialization of let data to below:

      let data = {
        code: `const viewer = new Cesium.Viewer("cesiumContainer");\nconsole.log("Sandcastle loaded");\n`,
        html: '<style>\n      @import url(../templates/bucket.css);\n    </style>\n    <div id="cesiumContainer" class="fullSize"></div>\n    <div id="loadingOverlay"><h1>Loading...</h1></div>\n    <div id="toolbar"></div>\n    ',
        baseHref: "http://localhost:8080/Apps/Sandcastle/gallery/",
      };
      window.sandcastleData = data;
      if (window.location.hash.indexOf("#c=") !== 0) {
        document.head.innerHTML = `${document.head.innerHTML}<base href="${data.baseHref}" />`;
      }

Weirdly when I first did this the css was not loading/importing correctly and had the same error state. I thought this was good as a reproducible example. However sometime in my testing it started working again and I don't know what I changed. When putting the same code into a sandcastle (and not on the branch for #12704) and opening the standalone version it does not work. Comparing the "final html" of this vs the modified standalone.html file they are identical (apart from the size of the cesium canvas because of the styles not loading). It's still a mystery why one works and the other doesn't...

[jjspace]

I also confirmed the failure to load the css is unrelated to loading the Cesium viewer. If you comment out/remove the Cesium.Viewer initialization it still fails to load. When doing this the "success state" is a black screen, the "failed state" is still seeing the white background with Loading... in the top left.
(this can help save computer resources from initializing the Cesium Viewer and the WebGL context while testing)

[javagl]

I also tried to create something that is more standalone, but didn't manage to create an example where the issue could be reproduced. The idea was to have something that is unrelated to CesiumJS, to verify that this indeed is a FireFox bug. It seems like it sometimes does simply not properly process and fill in the external CSS after setting the part that refers to it as the innerHTML. But any attempt to do only and exactly that didn't lead anywhere. I'll attach it here nevertheless...

Cesium issue 12700 FireFox.zip