Add hidden input to ColorPickerField to prevent false unsaved warning

[davidcolquhoun]

Description

Fixes a bug where the CMS would display a false “Are you sure you want to leave?” warning when editing a page that includes a ColorPickerField, even if no changes had been made.

This happened because the initial Field() HTML output didn’t include an <input> element with the field value. React inserts it later, but too late for Silverstripe’s form state tracker, which compares the initial DOM snapshot to detect changes. As a result, the presence of this newly-added hidden input triggers the “unsaved changes” warning.

The bug typically only shows up when an UploadField (e.g. an image field) is present on the same form. That’s because the CMS changes how it tracks form state when file fields are involved. It takes a stricter snapshot of the entire form, making it more sensitive to any unexpected DOM changes.

This fix appends a hidden input directly in ColorPickerField::Field() to ensure the value is present from the start, before React mounts and alters the DOM.

Manual testing steps

1. Create or edit a page that includes a ColorPickerField and an UploadField (e.g. an image).
2. Load the form and make no changes.
3. Attempt to navigate away.
4. Expected: No “unsaved changes” warning appears.

Without this patch, step 4 incorrectly triggers the warning.

Issues

No issue created yet

Pull request Checklist

• The target branch is correct
• All commits are relevant to the purpose of the PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[davidcolquhoun]

Hi @michalkleiner is this repo still maintained? do you know anyone who could review this?

[davidcolquhoun]

I guess this repo is abandoned then.

[michalkleiner]

Sorry, missed the notification. Will have a look.

[michalkleiner]

I wonder whether that should be adjusted in core instead to skip <input type="hidden"> fields in the change tracker. What do you think @GuySartorelli?

[GuySartorelli]

Unfortunately that would break a few complex field types where we rely on a hidden field to clue the change tracker in on values that are otherwise only held in state.

[GuySartorelli]

The bug typically only shows up when an UploadField (e.g. an image field) is present on the same form. That’s because the CMS changes how it tracks form state when file fields are involved. It takes a stricter snapshot of the entire form, making it more sensitive to any unexpected DOM changes.

I wasn't aware of this though - it might be that we need to revisit how this works and see if there's a better way to handle upload fields.

[michalkleiner]

For the change here, is that an ok workaround for now, explicitly adding the hidden field?

[GuySartorelli]

I suspect so - if it's inside the container element that react will bind to, then the temporary hidden field will be removed when react does its thing.

There will be a brief moment when the old hidden field gets removed from the DOM before the new one gets added, so it's theoretically possible the change tracker might notice this and think it's a change? But if that doesn't happen then it should be fine.

tl;dr if it works then it works 😅

[GuySartorelli]

There's probably some way around it that doesn't require doing that, since we have other react fields that add hidden fields which don't need this workaround - but off the top of my head I don't know how they deal with this problem.

[michalkleiner]

@davidcolquhoun would you potentially have a bit more time to check how other React fields do their thing with hidden inputs?

[davidcolquhoun]

@michalkleiner hey, sorry but this was from 6 months ago. I can't remember which site I needed this fix for.