Binary field stuck on infinite loading spinner when creating new content (legacy Dojo/JSP editor)

Problem Statement

When creating new content of any content type that has a Binary field, the Binary field area renders a loading spinner that never resolves. The rest of the fields render normally. Editing existing content of the same type works correctly.

The field never becomes usable, so the file cannot be uploaded. The only way to save is to make the Binary field optional and save while ignoring the spinner.

Reported by a customer (Freshdesk #39006) running 25.07.10_lts_v16, where it blocks their pre-cutover upgrade — several of their content types use Binary fields. Affects the legacy Dojo/JSP content editor. Browser-independent (reproduced in Chrome; it is not a rendering issue).

Root cause

All three defects are in dotCMS/src/main/webapp/html/portlet/ext/contentlet/field/edit_field.jsp, inside the autoexecute IIFE (~lines 800–895 in main):

1. The request is made with no id. On create, inode is empty (line 66: String inode = inodeObj != null ? inodeObj.toString() : ""), so the script calls fetch('/api/v1/content/'). That path never matches the JAX-RS route and returns 404 every time.
2. The response status is never checked. The code goes straight to response.json() without testing response.ok.
3. The error handler has a typo. The .catch assigns binaryFieldContainer.innerHTMl — lowercase L — instead of innerHTML (line 890 in main, 877 in v25.07.10_lts_v16). This writes an inert JS property, so the original spinner markup is never replaced and no error is ever shown.

Why it only reproduces in some environments

Whether the bug is visible depends entirely on what the 404 response body happens to be, which varies by environment:

The customer's response headers confirm theirs returns HTML:

Content-Type: text/html;charset=UTF-8
X-DOT-VanityUrl: 9cb6dbe2-0a5b-4e71-a29b-8ba02107eb63

That is the same vanity serving /home/error-pages/cms404page in their logs.

Evidence from local reproduction

Reproduced on dotcms/dotcms:25.07.10_lts_v16. With a non-parseable 404 body, in create mode: spinners: 1, binaryEls: 0 — the dotcms-binary-field web component is never created at all.

The typo captured live on the stuck container:

{
  "hasTypoProp": true,
  "typoValue": "<div class=\"callOutBox\">Error loading the binary field</div>",
  "realInnerHTML_stillSpinner": true
}

The error message is generated — it just lands on a property that does not exist in the DOM.

Note: this closes an earlier open caveat on the Freshdesk ticket, which concluded the JSP bug "does not appear sufficient on its own" to explain the permanently stuck field and proposed a stale-cached-JS theory. That theory is not needed: the earlier reproduction simply had a 404 body of 404, which parses successfully. The JSP bug is sufficient on its own.

Steps to Reproduce

1. Run dotcms/dotcms:25.07.10_lts_v16 (or main) in an environment where GET /api/v1/content/ returns a non-JSON body — either empty or the site's HTML 404 page.
2. Create a content type that has a Binary field (e.g. a FILEASSET base type).
3. Go to Content and create new content of that type using the regular (non-beta) editor.

Expected: the Binary field loads and accepts a file upload.
Actual: an infinite loading spinner; the field never becomes usable and no error message is displayed.

To confirm the environment is in the failing state, check the response body of GET /api/v1/content/ in DevTools → Network. A body of 404 hides the bug; an empty or HTML body exposes it.

Editing existing content of the same type works correctly in both cases.

Acceptance Criteria

• Creating new content of a type with a Binary field renders a usable Binary field (no spinner), regardless of what the environment's 404 error page returns
• No request to /api/v1/content/ is issued when inode is empty — the 404 is eliminated at the source rather than handled
• response.ok is checked before response.json() is called, so a non-2xx response never reaches the JSON parser
• The innerHTMl typo is corrected to innerHTML, so a genuine failure replaces the spinner with the error message instead of leaving it spinning
• Editing existing content with a Binary field continues to work — the component still hydrates from the fetched contentlet (no regression)
• The fix is verified in an environment where GET /api/v1/content/ returns a non-parseable body, not only in one where it returns 404
• Fix landed in main and backported to the 25.07.10_lts branch

dotCMS Version

Reported on 25.07.10_lts_v16. Reproduced locally on the same image.

The bug is not a regression — edit_field.jsp is identical across 25.07.10_lts_v10, 25.07.10_lts_v16 and main (verified by diff), so content creation has always been broken on this path. The typo is still present in main at line 890.

Requires the fix in main plus a backport to 25.07.10_lts.

Severity

High - Major functionality broken

Links

• Freshdesk ticket #39006 — binary type field not loading for any content type
• Slack thread
• Affected file: dotCMS/src/main/webapp/html/portlet/ext/contentlet/field/edit_field.jsp
• Related: dotCMS/src/main/webapp/html/error/custom-error-page.jsp (determines the 404 body shape that makes the bug visible)

Workarounds

Only the Edit Content Beta editor avoids the issue, since it does not use this JSP. The reporting customer declined it because it is still in beta. No configuration workaround exists — SIMPLE_ERROR_PAGES_FOR_BACKEND was tested on the customer's environment and did not help.

Start in dotCMS/src/main/webapp/html/portlet/ext/contentlet/field/edit_field.jsp, especially the inode setup and autoexecute IIFE, and reproduce creation of a Binary field with a non-JSON 404 response. Trace the request, response handling, and catch path, then verify that new content loads a usable field, existing content still hydrates, and the fix is checked on main and the 25.07.10_lts branch.