Unidentified CSS loading problems, possibly timing-related?

[BuntlineAtSea]

I'm asking this as a question rather than raising a bug, as I don't know whether this is a defect in django-formset or a mistake in how I'm deploying it. Either way, I would greatly appreciate some help as we're rapidly approaching a ship date and I'm out of ideas.

For me, Formset has been behaving perfectly. However, one of my testers reports intermittent but very frequent javascript errors in the PhoneNumber, DateTime, and DjangoSelectizeCountry widgets. When these occur (which seems to be more often than not, for him) the widgets in question don't render properly and the form doesn't work. He's sent me this screenshot:

Most searches for that error relate to cross-domain issues, but on my site everything is being loaded through a single Nginx server (gunicorn for the Django and static web serving for JS and CSS files) so I don't think that's the issue here.

As mentioned, I haven't been able to reproduce this in Safari, Chrome, or Firefox on my M4 Mac. However, with the goal of testing everything, this evening I pulled an old and painfully slow Windows laptop off the shelf. In Chrome on that machine, I can fairly reliably trigger similar - but not identical - errors:

In this example, it's an image upload widget and the country selector that are not working.

The fact that this manifests on my slowest computer but not any of the three faster ones I tried (including Chrome on Windows on a slightly faster laptop) makes me wonder if it's a timing problem. But that's just a guess.

Unfortunately I'm not really a front-end developer (the last time I did anything browser-based professionally was nearly 20 years ago) so I'm unsure how to track down problems in modern javascript. I just have the minified files being statically served, not any sort of javascript build system. The top bug in the above screenshot clicks through to this location in the prettyprinted minified JS, if that helps:

Any suggestions would be extremely welcome at this point. I'm starting to think I might have to strip out these widgets if I can't fix it, which I really don't want to do as I like the modern feel they give to the site. But better a boring textbox than a form that doesn't work for some people.

Many thanks for any assistance.

[BuntlineAtSea]

I've found a possible lead - this article: https://medium.com/better-programming/how-to-fix-the-failed-to-read-the-cssrules-property-from-cssstylesheet-error-431d84e4a139

I can't get hold of my tester right now to check if he has any browser extensions installed - but does Django-formset try to do anything with "all" stylesheets, and might sometimes be getting more than it expects, as described in the article?

[jrief]

That's interesting. I never encountered this error myself. Just for your understanding, django-formset creates its own CSS rules while bootstrapping the web components (aka Django widgets).

[jrief]

I just read the linked article. This does apply to django-formset, because the CSS styles are loaded together with JavaScript. So my question is:
Are your JavaScript files served by the same host as your HTML?

Other hints:
Compile the project in debug mode, this gives much better feedbacj where certain errors occure.

Try to use the monolithic build. You can remove the web components you don't need in your project to keep the payload smaller.

[BuntlineAtSea]

Thanks for looking at this.

Yes, everything I want to load is loaded from the same place - in fact the same nginx instance on a single VM. It's a relatively low-traffic site and I wanted to keep things simple. Here you can see everything being loaded from my staging subdomain, except for a couple of google fonts being pulled in by a pre-canned theme I'm using:

I don't think the fonts can be the problem here, because they will always be pulled in from elsewhere, but I don't see the rendering issues in my copy of Chrome.

The article is a little unclear in that it starts with what wasn't the author's problem, loading CSS in the page from other domains. It's only towards the end that he talks about what the actual issue was - browser extensions loading external CSS:

We can't control if users are doing that, and it would explain why my tester is seeing this issue and I'm not, since Chrome isn't my primary browser and I don't have any extras installed in it.

I will try your other suggestions this evening - about ten hours from now, since I suspect we're in very different timezones. If there are any instructions on how to do that I'd be grateful, as I'm a little out of my depth with modern javascript build systems. Things have changed a lot since I worked on the web UI for an IBM internal tool back in 2006 :).

Thanks.

[jrief]

I just asked Github Copilot, and that's its answer:

May you please change that statement to this proposal, recompile and try again.
I'm actually wondering, why your developer tools mark this as TypeError.

[jrief]

Claude's answer:

[BuntlineAtSea]

Sorry it's taken me a little while to get back to this.

With the debug version hooked into my project, I could see that the error originated at line 125 of helpers.ts. Accessing cssRules on one of the stylesheets was throwing a SecurityError.

(Unfortunately I didn't have my tester capture the raw error before I added a try/catch with debug message around the offending line, hence the slightly different line number shown in the screenshot).

As you can see, the stylesheet in question is being loaded from google. I don't know why; grep -r finds no mention of it anywhere in my project tree, so the browser extension theory still seems plausible especially since it doesn't happen on my machine. In any case, your code isn't allowed to access that stylesheet's cssRules property in modern versions of Chrome, and shouldn't be trying to (or should fail silently).

For my own purposes, I've patched the code like this:

export function stylesAreInstalled(baseSelector: string) : CSSStyleSheet|null {
	// check if styles have been loaded for this widget and return the CSSStyleSheet
	for (let k = document.styleSheets.length - 1; k >= 0; --k) {
		try {
			const cssRule = document?.styleSheets?.item(k)?.cssRules?.item(0);
			if (cssRule instanceof CSSStyleRule && cssRule.selectorText.trim() === baseSelector) {
				return document.styleSheets.item(k);
			}
		} catch (e: any) {
			if (e.name === 'SecurityError') {
				// Trying (and failing) to load a stylesheet from another domain.
				// It won't be the one we're looking for, so just swallow the error.
			} else {
				throw e;
			}
		}
	}
	return null;
}

I'm not a JavaScript guy, still less a TypeScript one, so you may well have a better solution here. But this solves my immediate problem. Hopefully it can be addressed in the next release so that I don't have to keep patching it when upgrading.