ChoiceType returns wrong data on submit if clearMissing is false

[ossinkine]

I've created TestFormType

class TestType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('text', 'text')
            ->add('choice', 'choice', ['choices' => ['FOO' => 'foo', 'BAR' => 'bar'], 'expanded' => true])
        ;
    }

    public function getName()
    {
        return 'test';
    }
}

created the form and trying to submit data

$data = [
    'text'   => 'foo',
    'choice' => 'foo',
];
$form = $this->createForm('test', $data);
$form->submit(
    [
        'text'   => 'bar',
        'choice' => 'bar',
    ],
    false
);

and now $form->getData() will return an array:

array (size=2)
    'text' => string 'bar' (length=3)
    'choice' => string 'foo' (length=3)

I expect to receive bar for both fields.

I'm working on the latest version of 4.4 branch
See the reproducer for this issue https://github.com/ossinkine/symfony-issue-16802

[stof]

@webmozart can you take a look ?

[1ed]

@ossinkine the choices option actually looks like this [0 => 'foo', 1 => 'bar'] and by default the keys used as values in the HTML select element so the submitted value should be 1 to select the bar option, shouldn't it? See http://symfony.com/doc/2.7/reference/forms/types/choice.html#example-usage

[ossinkine]

@1ed My bad.
I fixed choices option in the form. Also, I added expanded option. The issue is reproduced.
I made changes in the first comment and in my fork.

[geoffrey-brier]

@stof @webmozart Just upgraded in 2.8 and I'm facing the same issue. Seems like it comes from the expanded option being set to true, it's as if the data wasn't properly cleaned in the ChoiceType class.

The following code fixes the problem, but I'm really not sure if that's the way to fix it.

<?php
// Symfony\Component\Form\Extension\Core\Type\ChoiceType.php
    foreach ($form as $child) {
        $value = $child->getConfig()->getOption('value');

        // Add the value to $data with the child's name as key
        if (isset($valueMap[$value])) {
            $data[$child->getName()] = $value;
            unset($unknownValues[$value]);
            continue;
        }
        // Doing this fixes the problem
        $data[$child->getName()] = false;
    }

[HeahDude]

Hi @ossinkine, I can confirm your issue, a workaround it to call the field data :

$form->get('choice')->getData()
// will get the expected
string 'bar' (length=3)

It's a problem of propagation of submitted data.

I'll send a PR as a proposal to fix this issue, thanks for reporting it.

Status: reviewed

[HeahDude]

Hi @ossinkine, could you please try the fix provided in #17771 to see if it works for your issue ?

[ossinkine]

Hi @HeahDude
It seems to be working for me

[HeahDude]

Thanks for the feedback.

[ureimers]

So as #17771 is closed without a pull (for good reasons, I suppose) this problem still exists in all current Symfony versions.

[xabbuh]

This seems to have been fixed in the meantime as I can no longer reproduce.

[ossinkine]

The issue is still reproduced.
There is the reproducer for Symfony 4.2 https://github.com/ossinkine/symfony-issue-16802

[ostrolucky]

you might want link this url to one remaining linked issue that is still open

[alexander-schranz]

I did fall into this issue.

So currently the ChoiceType is given clearMissing = false here:

symfony/src/Symfony/Component/Form/Form.php

Line 578 in dbe37de

$child->submit($isSubmitted ? $submittedData[$name] : null, $clearMissing);

Maybe we should introduce a new form configuration e.g.:clear_missing which can be true|false|null where null means = inherit from parent. And the ChoiceType default value is false true.

@xabbuh @HeahDude what do you think?

[xabbuh]

Would #35938 help here?

[alexander-schranz]

@xabbuh did test it but sadly that does not solve this issue.

[alexander-schranz]

@xabbuh oh you asked if it helps. Basically we could go on that flag and do:

if ($child->getConfig()->getAttribute('_false_is_empty')) {
    $clearMissing = true;
}

$child->submit($isSubmitted ? $submittedData[$name] : null, $clearMissing);

at

symfony/src/Symfony/Component/Form/Form.php

Line 578 in dbe37de

$child->submit($isSubmitted ? $submittedData[$name] : null, $clearMissing);

and then the entity looks good for me.

But not sure if its a good idea to go on that flag and how it will be solved in Symfony 5.1. /cc @fancyweb @HeahDude

[bluser86]

We have run into this issue today as well on symfony 5.1.3. We found that a form eventlistener helped us work around the issue:

<?php

namespace App\Form\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\Form\Event\PreSubmitEvent;
use Symfony\Component\Form\FormEvent;
use Symfony\Component\Form\FormEvents;

class ChoiceSubscriber implements EventSubscriberInterface
{
    /**
     * {@inheritdoc}
     */
    public static function getSubscribedEvents()
    {
        return [
            FormEvents::PRE_SUBMIT => 'onPreSubmit',
        ];
    }

    /**
     * @param PreSubmitEvent $event
     * @throws \Symfony\Component\Form\Exception\OutOfBoundsException
     * @throws \Symfony\Component\Form\Exception\RuntimeException
     * @throws \Symfony\Component\Form\Exception\TransformationFailedException
     */
    public function onPreSubmit(PreSubmitEvent $event)
    {
        $form = $event->getForm();
        $data = $event->getData();

        if (isset($data['choice']) && $data['choice'] !== $form->get('choice')->getData()) {
            $form->get('choice')->setData(null);
        }
    }
}

The work around constitutes checking during the pre submit event if the submitted data has changed compared to the pre-populated form data. If this is the case reset the current form data to null. Hopefully this helps others who might run into this problem in the future until a patch is made to fix it.

[carsonbot]

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

[ostrolucky]

.

[xabbuh]

I am not sure I understand the issue. Submitting invalid values to a choice type means that a TransformationFailedException is being thrown and thus the data is not going to get mapped back to the underlying object. This is expected.

[ostrolucky]

Indeed, I think this can be closed after all. Problem in post of OP was that he is submitting choice key instead of value.

[ossinkine]

I'll update my reproducer to the latest Symfony 4.4 and try to reproduce.

[ossinkine]

I've updated Symfony in my reproducer to the latest 4.4 version and the issue is still reproducer.
@xabbuh @ostrolucky Why do you guys think I submit invalid values to choice? I submit foo value which is one of choices. If you look at first post and see choice values as keys, such behavior was in Symfony 2.7 (this was the most actual version when issue created). In the fresh reproducer the values set up correctly, please review https://github.com/ossinkine/symfony-issue-16802

[ostrolucky]

No, FOO and BAR are valid choices. Choice keys were used by default in Symfony 2.x, but it was deprecated since 2.8 and values were made default since 3.0 https://symfony.com/doc/2.8/reference/forms/types/choice.html#choices-as-values

[ossinkine]

@ostrolucky please look at reproducer https://github.com/ossinkine/symfony-issue-16802/blob/771f6579ad4ba7c27b1d9bf44d4db0c8092588c2/src/Form/TestType.php#L17

        $builder
            ->add('text', TextType::class)
            ->add('choice', ChoiceType::class, ['choices' => ['FOO' => 'foo', 'BAR' => 'bar'], 'expanded' => true])
        ;

choices are values, so foo and bar are valid

[xabbuh]

Thanks, I can now reproduce it.

Status: Reviewed

[ostrolucky]

Could you please also update original post?

[ossinkine]

@ostrolucky updated

[xabbuh]

Can you try out #40417 please?

[ossinkine]

Thank you @xabbuh, your fix fixes the issue for me