Web editor never loads — the create-model / editType=editModel route renders blank, embedded or standalone

Software Creality Cloud
,
1

Web editor never loads — the create-model / editType=editModel route renders blank, embedded or standalone

Summary: Clicking Edit on any of my models navigates to the edit URL, renders the page shell, and then leaves the entire main content area blank. The editor component never mounts. The mobile app edits the same models without any problem.

This is not a caching or environment issue on my end — I’ve isolated it fairly thoroughly (details below). It looks like a client-side regression in the web app.

Environment
Account MakerX (ID 3092010586)
URL pattern crealitycloud.com/user/3092010586/create-model?groupId=<id>&editType=editModel
Affected Chrome + Edge on Windows 11 (home desktop), Chrome on a separate work computer, Chrome on Android
Working Creality Cloud mobile app — edits succeed normally
First noticed Friday 17 July 2026 (work computer); re-confirmed 19 July 2026 on two further devices
Support ticket #20260720893877

Prior contact

I first hit this on Friday 17 July on my work computer and raised it through Creality support chat. I was advised to try a different computer. I did exactly that on 19 July, on two further devices and two further networks, and the failure is identical in every case. This report is the result of that follow-up testing.

Creality support chat has logged this as ticket #20260720893877.

What I ruled out

  • Cleared cache and cookies in both browsers
  • Chrome incognito (no extensions)
  • Full PC reboot
  • Three separate machines — home desktop, work computer, and an Android phone — across two operating systems
  • Three separate networks — work network, home Wi-Fi, and cellular with Wi-Fi disabled (different IP, ISP and DNS in each case)
  • Both dark and light theme
  • Multiple different models — fails on all of them

Same result every time in the browser; the app always works. That points at the web client rather than my environment, my account, or the model data.

Symptoms

The page navigates correctly and the shell renders fine — top nav, profile sidebar, stats, and the Home / 3D Model / Favorites Folder / Print Files / Prints & Score / Community tab row are all present and correct. The session is clearly authenticated, since profile data loads.

The entire main content region below that stays empty. The editor never appears.

Console

Two lines repeat continuously and indefinitely, at high speed, from bundle 0fe0128….js:1:

JYF-handleIframeMessage  MessageEvent {isTrusted: true, data: {…},
    origin: 'https://www.crealitycloud.com', lastEventId: '', source: Window, …}
postMessageTheme dark https://www.crealitycloud.com

In light mode the second line becomes postMessageTheme light — otherwise identical. The loop does not terminate; it continues for as long as the tab is left open.

Network

No request fails. I filtered with -status-code:200 across the All request type and got no 4xx, no 5xx, and no failed document request. The only non-200 rows are Google Analytics / GTM beacons returning 204 (which is normal for beacons) plus a handful of cancelled beacons.

However, the total request count climbs continuously on a completely idle page:

189 → 642 → 1091 → 1540 → 2438 …

Those are overwhelmingly collect?v=2&tid=G-G7YED6183T, 315437176?gtm=…, and rum calls — i.e. each iteration of the message loop is firing another analytics beacon. An idle stuck tab generates thousands of requests.

DOM

The only <iframe> in the document is height="1" width="1" with visibility: hidden — a tracking pixel, not the editor. There is no editor iframe present.

Inspecting the blank region resolves to <body> itself, not to an empty or collapsed editor container. <div id="__nuxt"> is present and the _nuxt/*.js bundles all load successfully.

So the editor component is not rendering empty — it never mounts in the first place.

The editor is an embedded FlowPrint page

The Google Analytics beacons fired from the stuck page carry a dl (document location) parameter identifying what the embedded frame believes it is. Decoded:

https://www.crealitycloud.com/flowprint/iframe-embedded-page/user/3092010586/model?cre-theme=light

Three things follow:

  • The editor is served as a separate embedded application under /flowprint/iframe-embedded-page/, not as part of the main Nuxt app.
  • The accompanying dt (document title) parameter is empty — consistent with a page that initialises far enough to fire analytics but never renders.
  • The theme is passed twice: once as the cre-theme query parameter on that URL, and again over postMessage via postMessageTheme. That duplication is a plausible origin for the loop.

Requests for main.js in this context also return 302 redirects.

Minimal reproduction: the failure is in the create-model route itself

Loading these FlowPrint URLs directly in their own tab, with no iframe involved, isolates the fault to a single route:

URL Result
/flowprint/iframe-embedded-page/user/3092010586/model?cre-theme=light Renders correctly. Complete model grid — all folders, all model cards, view/download/like counts, print-configuration links. Fast, no errors.
/flowprint/iframe-embedded-page/user/3092010586/create-model?groupId=<id>&editType=editModel&cre-theme=light Blank. Renders the FlowPrint shell — profile sidebar, stats, and the Models / Print Settings tab row — then leaves the content area completely empty. Identical to the failure seen inside the iframe.
/flowprint/user/3092010586/create-model?groupId=<id>&editType=editModel 404 (incorrect path — listed only for completeness).

This is the key finding. The model route renders correctly and the create-model route renders blank, and both behave the same way whether or not they are embedded. The fault is therefore not in the embedding layer, not in authentication, and not in the model data — it is in the create-model route itself.

The second URL above should be a complete, self-contained reproduction.

Where I think it’s going wrong

The theme-sync handshake looks like it has no loop guard. handleIframeMessage appears to respond to an incoming message event by calling postMessageTheme, which posts back to the same origin, which re-triggers handleIframeMessage, and so on without a terminating condition or an origin/source check to distinguish its own echo from a genuine inbound message.

Since the loop occurs identically in both themes, the theme value isn’t the trigger — the handshake itself is.

Because the create-model route fails identically whether embedded or loaded standalone, while its sibling model route works in both cases, the defect is in that route’s own rendering path. The page initialises far enough to draw the FlowPrint shell and fire analytics, but the view itself never mounts and the document title is never set.

The looping postMessage handshake is described above because it is clearly abnormal and worth fixing on its own account — a single idle tab issuing thousands of requests is a real problem. But it is most likely a second symptom rather than the cause, since the standalone reproduction needs no parent frame to fail.

Worth noting: this may only reproduce on the editType=editModel path, since the rest of the site behaves normally in the same session.

Questions

  • Is this a known regression? It was already failing on 17 July 2026, and my last successful web edit was a few weeks before that, so it landed somewhere in that window.
  • Is anyone else seeing a blank editor on editType=editModel?
  • Is there a supported workaround besides the mobile app?
  • Does the standalone create-model URL above render blank for you as well?

Happy to supply a HAR file, full console export, or test any build you’d like.

2

Resolved by Creality on Monday 20 July; the edit flow now uses a create-model-new route