[4.x]: JS Error preventing addition of a new Table field

[rob-c-baker]

What happened?

Description

A JavaScript error prevents the ability to define a new "Table" field in the CMS:

Steps to reproduce

1. In CMS > Settings > Fields > [ + New Field ] > New Field Screen
2. Select "Table" from the "Field Type" drop down
3. JS error in console: "VM1408:1 Uncaught TypeError: Craft.TableFieldSettings is not a constructor" (using Chrome 116.0.5845.188)
4. Cannot use most of the controls on page to define the new field

Expected behavior

No JS error and the field can be defined.

Other detail

Clearing caches including "control panel resources" has no effect. This also happens when I disable all our module's custom JS / CSS that would normally be injected into the CMS.

Craft CMS version

4.5.4

PHP version

8.1

Operating system and version

N/A

Database type and version

N/A

Image driver and version

N/A

Installed plugins and versions

• Asset Rev 7.0.0
• CP Field Inspect 1.4.4
• Feed Me 5.2.0
• Field Manager 3.0.7
• Minify 4.0.0-beta.2
• Redactor 3.0.4
• Retcon 2.7.3
• Retour Redirects 4.1.13
• SEOMatic 4.0.31
• Smith 2.0.0
• Super Table 3.0.9
• Twig Perversion 3.0.0
• Twig Profiler 4.0.0-beta.1
• Wordsmith 4.2.0

However, the issue also happens when all plugins are disabled.

[rob-c-baker]

Upon further testing, it looks like I am getting similar JS errors when selecting most field types in the same drop down.

It looks like it happens with any field that requires another JS file to be loaded. Looking at the network tab the files that the error claims are missing are in fact being loaded - just not being executed? Or not being execute in time - perhaps a race condition.

Whether it's just me getting this or everyone, I'm not sure.

[rob-c-baker]

This does not happen on a different Craft install we have on the exact same version. I have been checking the differences and on the install where this does not work, all static content (i.e. css / js / etc) is served via a different hostname (which is a subdomain of the main domain the control panel is served from). It is achieved by setting these general config properties:

[
    ...
    'resourceBasePath' => '[fs path to doc root of alternate hostname web server]',
    'resourceBaseUrl' => 'https://[alternate hostname]/...',
    ...
]

This is done for various reasons I could go into if needed.

I should say that this is a new issue since we upgraded to 4.5.4 from the previous version 4.4.5 - it was working this way fine since the version 3 days and there are no errors in the browser console to offer clues. My guess would be a side effect of a security http header along the line somewhere, which is what I'm checking next.

[brandonkelly]

I should say that this is a new issue since we upgraded to 4.5.4 from the previous version 4.4.5 - it was working this way fine since the version 3 days and there are no errors in the browser console to offer clues.

Nothing has changed in Craft recently that should affect this – in fact we can reproduce the same issue with Craft 3 even. So my guess is that Chrome was recently updated and that somehow affected how crossdomain JS scripts are getting loaded. In our testing, the scripts do in fact get loaded; just asynchronously, and so not in time for the subsequent JS code that is expecting the remote script to have already been loaded & executed.

It’s now fixed for the next Craft 4 release. We’re now parsing out any remote JS resources that were registered to the Ajax request, and loading them directly via $.getScript(), and only appending the remainder of the Ajax-provided head/body HTML after all remote scripts have been loaded.

[rob-c-baker]

So my guess is that Chrome was recently updated and that somehow affected how crossdomain JS scripts are getting loaded

I think this is / was the key to the issue.

In our testing, the scripts do in fact get loaded; just asynchronously, and so not in time for the subsequent JS code that is expecting the remote script to have already been loaded & executed

Exactly what I was seeing, but looking at the code that includes these scripts, it should have been working fine - as you say - were are loading in an async manner, despite no async attribute on the script tag.

Many thanks for sorting this - will be nice to be able to go back to the previous set-up.

[brandonkelly]

Craft 4.5.6 is out now with that fix!