FAPI #states: dependent element added via AJAX initializes incorrectly if dependee has been initialized earlier

Leaving on D7 for now.

IMO it's more of a UX issue but there is indeed a bug. In the sample module, the #states behavior is initialized several times and pretty much confuse itself with default values and all.

Applying the patch from #1592688-32: #states can cause the form "required" mark to appear more than once on the same element to states.js should solve your issue. seems like it soved it for me in any case. It'd be great if you could roll the patch for the other issue :)

Our problem seems similar: we have a custom form with two managed file fields (which upload files using AJAX) and a text field. When either of the managed file fields has a file selected, the text field should appear. Though the text field does appear, after removing both files it does not disappear.

We use a visible state with OR condition that checks whether one of the managed files' values is a file ID other than 0:

$form['my_text_field']['#states']['visible'] = array(
  array('[name="my_managed_file_1[fid]"]' => array('!value' => '0')),
  array('[name="my_managed_file_2[fid]"]' => array('!value' => '0')),
);

First time Drupal.behaviors.states.attach is called

A data flag that is set on dependees that indicates the dependee has been initialized. On initialization amongst other things an event is bound to the dependee, but also it's value is being cached at DrupalStatesDependentInstance.values[selector][stateName].

Second time Drupal.behaviors.states.attach is called

After ie. uploading a file Drupal.behaviors.states.attach is called again.

Data flags have already been set on existing dependees, so they are not being initialized again. This prevents events from being bound twice, but also causes their values cached at DrupalStatesDependentInstance.values[selector][stateName] to remain at their initial values null as set in states.Dependent.prototype.initializeDependee().

Newly inserted elements by AJAX do not have the data flag set and are getting initialized.

Back to our example

After a file upload Drupal.behaviors.states.attach is called for the second time. The cached values of both managed file fields are initially set to null. The existing managed file field already had the data flag and is not being initialized, so it's cached value remains null and according to our state's conditions null !== '0' the text field wrongly(!) stays visible.

Data flag

The data flag is being used to prevent double events being bound to a dependee, the comments state:

// Only call the trigger initializer when it wasn't yet attached to this
// element. Otherwise we'd end up with duplicate events.

but this also causes the values cache not being initialized properly.

If the sole purpose is preventing double bound events, could we not A) remove this data flag completely and B) unbind possible earlier bound events before binding new ones?

In Drupal.states.Trigger (unpatched Drupal 7.28) I commented out the if statement (though javascript, I use PHP formatting for syntax highlighting):

states.Trigger = function (args) {
  $.extend(this, args);

  if (this.state in states.Trigger.states) {
    this.element = $(this.selector);

    // Only call the trigger initializer when it wasn't yet attached to this
    // element. Otherwise we'd end up with duplicate events.
//    if (!this.element.data('trigger:' + this.state)) {
      this.initialize();
//    }
  }
};

and in Drupal.states.prototype.defaultTrigger I commented out the old event binding and added a new line that first unbinds possible events using event namespacing:

  defaultTrigger: function (event, valueFn) {
    var oldValue = valueFn.call(this.element);
    // Attach the event callback.
//    this.element.bind(event, $.proxy(function (e) {
    this.element.unbind(event + '.statesnamespace').bind(event + '.statesnamespace', $.proxy(function (e) {
      var value = valueFn.call(this.element, e);
      // Only trigger the event if the value has actually changed.
      if (oldValue !== value) {
        this.element.trigger({ type: 'state:' + this.state, value: value, oldValue: oldValue });
        oldValue = value;
      }
    }, this));

    states.postponed.push($.proxy(function () {
      // Trigger the event once for initialization purposes.
      this.element.trigger({ type: 'state:' + this.state, value: oldValue, oldValue: null });
    }, this));
  }

I am pretty familiar with js / jQuery, the states script is pretty hard to get my head around. This fix works for me so far, does it help you?

The solution proposed by lmeurs corrects the issue in my case.
Here's a patch corresponding to his modifications.

Patch at #5 fixes similar issues encountered, #states not applied to dependant elements returned in an #ajax callback

Thanks for the patch and the review! If this is the way to go, than:

1. We no longer have to set the 'trigger:' + this.state data variable,
2. Alter the comments accordingly to the changes we have made, ie. "Attach the event callback." can become "Detach possibly earlier attached event callback using event namespacing and attach a new event callback.",
3. Use a more descriptive name for the event namespace, ie. "statesnamespace" can become "statesDefaultTrigger".

See patch attached.

Related issue #1091852: Display Bug when using #states (Forms API) with Ajax Request

The same problem exists in Drupal 8.0.X. I updated the patch against 8.0.X

The scratch.tar.gz is a 7 module.

$dependee can be empty also...

We need first to fix the issues in D8 before we can start backporting. The test will fail because the issue is tagged to D8.

I fixed the issue by adding a behavior detach function to the states object, that will set the this.element.data('trigger:' + this.state) to false.

  var original_states_detach = function() {};
  if (Drupal.behaviors.states.hasOwnProperty('detach')) {
    original_states_detach = Drupal.behaviors.states.detach;
  }

  Drupal.behaviors.states.detach = function(context, settings) {
    var $states = $(context).find('[data-drupal-states]');
    var config;
    var state;
    var il = $states.length;
    for (var i = 0; i < il; i++) {
      config = JSON.parse($states[i].getAttribute('data-drupal-states'));
      for (state in config) {
        if (config.hasOwnProperty(state)) {
          for (var selector in config[state]) {
            if (config[state].hasOwnProperty(selector)) {
              for (var trigger in config[state][selector]) {
                var $element = $(selector);
                var sanitized = Drupal.states.State.sanitize(trigger);
                if ($element.data('trigger:' + sanitized)) {
                  $element.data('trigger:' + sanitized, false);
                }
              }
            }
          }
        }
      }
    }
    original_states_detach(context, settings);
  };

Patch from #19 breaks javascript (missing ",").

This patch fixe the problem about duplicate call of Ajax when we trigger "add_more" button. This possibly fixe your problem too. I don't provide an interdiff because the previous patch is to D7 and break D8.

#24 does what it needs to.

An ajax replace with elements which contains state condition resulted in losing het information for the dependent elements.
This patched fixed it.

*edit* I mis-tested it, the fields don't disappear anymore, but there are not updated when the element changes

Here is a reroll with es6 file change as well.

Closing this issue as its a duplicate of #1091852: Display Bug when using #states (Forms API) with Ajax Request