Problem with Undo when using COLOR field in a description resource

spedler

I've encountered an odd problem when a plugin has a COLOR field in a description and Undo (Ctrl-Z) is hit after changing the colour.

The attached archive contains a small ObjectData plugin called 'Diamond' to demonstrate this (Windows only, debug build). If you install it then invoke it from the Extensions menu, you see it generates a simple polygon object. There are three parameters - height, width and colour.

To reproduce the problem, change either the height or width parameter to anything. Then, click the 'Color' coloured rectangle and in the colour dialog box change the colour to anything. The object colour changes as expected. Close the dialog, then hit Ctrl-Z to undo the colour change. The colour changes back, but also undoes the previous parameter change to width or height. In fact, if you didn't change anything other than the colour, then hit undo, the object is deleted. It's almost as if the effect is to undo two levels on the undo stack rather than one.

At first I thought this must be the code I used to change the colour (it's just a call to BaseObject::SetColorProperties()) but not so. Because, if instead of clicking the coloured rectangle you expand the COLOR field to show the colour sliders, you can change the colour using the sliders and undo works normally You can also modify the source so the object colour is not changed at all and the problem still occurs.

Unless I'm missing something really obvious this looks like a possible bug in the colour picker dialog implementation. (N.B. the full plugin source code is included in the archive.)

Steve

Diamond.zip

spedler

This post is deleted!

spedler

Apologies - the file upload to my original post doesn't seem to have worked. I tried a different link but that was deleted for some reason. Here's another attempt. You can download the file from my site using this link.

Hopefully that has worked!
Steve

ferdinand

Hey Steve,

Something with the forum uploads is buggy. For some people it works and for some it does not, it is rather mysterious. Could you share the console output of when the upload fails? I neither see something in the server logs nor can I reproduce this from my work machines or private machines. We will replace the forum soon, so I will not put too much work into this, but maybe there is a quick fix.

Regarding your issue: That sounds indeed like a bug, I will have a look. At first glance I do neither see anything in your code that stands out, such as dangerous NodeData::SetParameter code, nor are there issues like giving multiple elements the same ID in odiamond.h. We did touch the color picker a while ago (2025.X), so I would not rule out that we added some kind of bug.

Cheers,
Ferdinand

spedler

Hi Ferdinand,

Thanks for getting back to me. I'll try uploading the file again in this message and see what it says. Here goes: Diamond.zip
Well that failed. The error message was: "Error. Something went wrong while parsing server response"

I'll try again using a VPN: Diamond.zip

No, same error. Not sure what that means!

Steve

ferdinand

Hey Steve,

The toast messages of NodeBB are often not very helpful. What I meant was the JS console.

I do not even see the failed upload attempts in my server logs; which in combination with "Error. Something went wrong while parsing server response" sounds a bit like a severed session? I.e., the client is sending and server does not even consider looking at the data, resulting in a timeout?

E.g. this. Here it fails because I am using an unsupported filetype.

Just right click on the page, select inspect and then go to the console tab (which is usually the selected default). All modern browsers have this.

Cheers,
Ferdinand

PS: Please also expand the call stack like so:

Anlv

Hi Ferdinand,

Here is an identical situation. I can see the file upload progress reaching 100%, followed by the error message: "Error: Something went wrong while parsing server response."

Since I am unable to successfully upload the image, below is the console information I copied.

nodebb.min.js?v=0b8ddba251d:65  POST https://developers.maxon.net/forum/api/post/upload 403 (Forbidden)
send @ nodebb.min.js?v=0b8ddba251d:65
ajax @ nodebb.min.js?v=0b8ddba251d:65
(anonymous) @ nodebb.min.js?v=0b8ddba251d:51
r.fn.ajaxSubmit @ nodebb.min.js?v=0b8ddba251d:51
(anonymous) @ topic.1839ecb58ed413849a53.min.js:3
dispatch @ nodebb.min.js?v=0b8ddba251d:62
De.handle @ nodebb.min.js?v=0b8ddba251d:62
trigger @ nodebb.min.js?v=0b8ddba251d:63
(anonymous) @ nodebb.min.js?v=0b8ddba251d:63
each @ nodebb.min.js?v=0b8ddba251d:62
each @ nodebb.min.js?v=0b8ddba251d:62
trigger @ nodebb.min.js?v=0b8ddba251d:63
a.fn.<computed> @ nodebb.min.js?v=0b8ddba251d:65
push.43103.v.ajaxSubmit @ topic.1839ecb58ed413849a53.min.js:3
(anonymous) @ topic.1839ecb58ed413849a53.min.js:3
dispatch @ nodebb.min.js?v=0b8ddba251d:62
De.handle @ nodebb.min.js?v=0b8ddba251d:62

Cheers,
Anlv

spedler

Hi Ferdinand,

OK, I'll try that again. Trying upload: Diamond.zip

And the output (hope this is what you wanted!):
alt text

I can't even upload an image, this is a link to my site.

Steve

Anlv

@ferdinand Hi Ferdinand,

I reproduced the upload failure and found that it is caused by a Cloudflare Challenge, rather than NodeBB itself.

The upload request completes, but the response is:

Endpoint: POST /forum/api/post/upload
Status: 403 Forbidden
Server: cloudflare
cf-mitigated: challenge
Content-Type: text/html; charset=UTF-8
Ray ID: a1c1af0daaf34f1a-LAX
Time: 16 July 2026, 14:26:46 UTC

Cloudflare returns an HTML Challenge Page to the XHR upload request. NodeBB expects a JSON upload response, so its parser subsequently reports: “Something went wrong while parsing server response.” The 100% progress only indicates that the browser finished sending the request body.

Could you please look up this Ray ID in Cloudflare Security Events to identify which WAF/Bot Management rule issued the challenge? A narrowly scoped exception for POST /forum/api/post/upload may resolve it, since an interactive Challenge Page cannot be completed inside this AJAX upload request.

I tested with a small PNG file in Chrome on Windows. I can provide additional non-sensitive request details if needed.

Cheers,
Anlv

ferdinand

POST https://developers.maxon.net/forum/api/post/upload 403 (Forbidden)

That is the culprit. That is the data upload endpoint and something is not letting you even talk with it. Could be NodeBB misbehaving or some shenanigans by Cloudflare. I will see if I can find out more.

edit: now I see it too, this is some cloudflare misfire

Thanks for the info @Anlv

Anlv

@ferdinand A small update:

My first attempt to open the upload endpoint directly only returned Forbidden and did not display a visible Cloudflare verification page.

I then used a small userscript to submit a real multipart file upload as a top-level browser navigation instead of an XHR request. That request succeeded and returned the normal NodeBB JSON response:

{"status":{"code":"ok","message":"OK"}}

More importantly, after this top-level request, the forum’s normal attachment uploader also started working successfully.

This suggests that the top-level request allowed Cloudflare to complete or refresh its verification/clearance state, while the original XHR upload could not handle the HTML Challenge response. It appears to be a Cloudflare Challenge/clearance issue rather than a damaged file or a failure in NodeBB’s upload handler.

ferdinand

Hey, could you please try again

Anlv

@ferdinand Hi, I think the issue has been fixed. I just tried uploading an attachment (before uploading, I cleared the cache and changed the network environment), and it no longer prompts "Error: Something went wrong while parsing server response."

Thanks for your help,
Anlv

ferdinand

Hey @Anlv,

thank you for the confirmation and for the precise debug report.

Cheers,
Ferdinand

ferdinand

Hey @spedler,

I did give this a shot. I cannot reproduce this after even quite a few attempts, but one of my colleagues (Fritz) could. There is probably some undo code missing in the color chip dialog. I assume that was what you did, Steve, right? You set the color via the popup color chip dialog and not with the inline control? Fritz could reproduce this without your plugin. So, my hunch was right, your plugin is not the culprit.

Since I cannot fix what I cannot reproduce on my machine, I have created a bug ticket for this and sent it off to the owners of the COLOR control. The ticket is ITEM#652737 Parameters of type COLOR do not always correctly invoke UNDOs in descriptions.

Out of curiosity: Can you also reproduce this on your machine with a a builtin object, e.g., the Cube object? Fritz and I were both on macOS while testing. But this being OS-specific seems a bit unlikely.

Cheers,
Ferdinand

I have moved this topic into "bugs".

edit: As always with these things now I can reproduce it too