Remove the states.js overwrite as it was fixed upstream

Stick states.js in jquery_update/replace/misc/1.7/states.js.

Works perfectly for me. Thanks!

Oops, no it doesn't. It breaks on the value state, when referencing a select element.

Sorry, I'm having a theme error. Works fine.

Thanks for the review! http://drupalcode.org/project/jquery_update.git/commit/07db916

Like in #1448494: jQuery 1.7: field_ui.js use attr for property I think is better if we change that upstream. So I keep it open so we don't forget to remove what we did.

EDIT: I didn't open a new issue to keep stuff in context.

I was having problems with http://drupal.org/project/field-conditional-state not working properly (read: at all) with jquery_update 2.x-dev using jquery 1.7. I tracked this down to a slight difference in states.js that happened after Rob Loach's commit above. Specifically, this commit coming out of #735528: FAPI #states: Fix conditionals to allow OR and XOR constructions changes the Drupal.states.Dependent.prototype.compare function argument list, and consequently breaking field_conditional_states extension of that function.

This is an unfortunate side-effect of replacing core files which may change, so I agree this should ultimately be dealt with upstream, but I'm not really sure how to go about that. For the interim, in case others run across similar issues, I've attached a patch which replaces jquery_update's copy of states.js with the most current version from core, and re-applies Rob Loach's fixes to make it work for 1.7.

The title of the issue suggests that this is solved upstream on jquery's side. Is there an issue filed for that in their tracking system?

Reading the code of states.js I think the problem is here:

states.Trigger.states = {
  // 'empty' describes the state to be monitored
  empty: {
    // 'keyup' is the (native DOM) event that we watch for.
    'keyup': function () {
      // The function associated to that trigger returns the new value for the
      // state.
      return this.val() == '';
    }
  },

  checked: {
    'change': function () {
      return this.attr('checked');
    }
  },

We should replace

      return this.attr('checked');

by something like than return true or false (I think now we can have undefined...)

I have to try it to be sure, but perhaps it can give some pointer to other.

Because now is broked, my advice will be to make a patch on state.js than works with core and jquery update, so we can after to send it upstream.

Spiderman's patch really needs to go to next release.

I had problems with the states.js that comes with the module as well. Same problem as here #1815896

After applying the patch in #8 the problems are solved. So i hope this patch moves into the next release.

However i did find a small bug. When there is a select multiple field, and there is a condition that should hide another field when this select multiple field is empty. Then the initial trigger will not do anything cause the .val() of the select multiple when empty is 'null'. And the function that updates the statuses checks initially that the new value is actually new. And since it compares with null, it will think that nothing changed and the condition will not apply.
So when the select multiple (dependee) is empty, it will not hide the dependent initially (on page load for example). as it should.

Attached a little tweak that should work. Just a workaround until there is a proper solution.

#8 fixes it for me also

Tis the wrong issue for the patch (since this is about fixing it upstream and not one of the several 'states are broken' issues), but it's a solid patch and fixes a bad issue, so perhaps it can go in soon?

I agree this should be fixed in core but we needed this fixed urgently and #8 fixed it for me.

Cheers

This worked for me, too... would be awesome if it made it into a release.

Ok, I need jquery 1.7 in admin so I'm going to fix that for good.

The core issue #2018791: states.js is not compatible with jquery +1.6.1 because it use $.attr in the wrong way. It will really help if you can provide some reproducible bug than append when using jquery_update with jquery 1.6+ with core states.js (just comment the line "$javascript['drupal.states']['js']['misc/states.js']['data'] = $path . '/replace/misc/1.7/states.js';" in jquery_update module).

I was having the issue, where multiple values weren't accepted in 'visible' states.

i.e:

    '#states' => array(
      'visible' => array(
       ':input[name="operation"]' => array(
          array('value' => 'infinity_fetch_products'),
          array('value' => 'infinity_sync_products'),
        ),
      ),
    ),

threw the js error: Uncaught TypeError: Object 0 has no method 'charAt'

The patch #8 fixed it for me too, allowing the visible state to be triggered by multiple possible options in the select box.

Patch in #8 fixed issues for me, too. This really needs to be committed to the module - wasted half a day debugging the project only to narrow it down to jquery_update's states.js!

I second that! The patch in #8 works great. Please commit this soon!

@gagarine said:

We should replace

return this.attr('checked');

... with this:

return this.is(':checked');

? Doing that fixed a bunch of problems for me, even after applying the patch.

Neither #8 or #20 solved a similar issue for me. I was encountering an issue where another module was either returning 0 or sending an integer in as the state. However, since this makes use of charAt(0) to remove the ! from the state - sending anything other than a string breaks the rest of the script. To solve this problem I simply ran this.name through .toString(). This fixes things for me

@ethanhinson: So you were having a different problem? This belongs in a different thread then, as the suggestions here do fix the problems they address.

#21 solves the problem for me.

I had this on my checkoutpage in drupal commerce for the first time.

+1 this fixes my issue too, not sure if this is the exact same issue as the original thread but it sure is an issue with states.js and jquery update :)

Thanks!

@RobLoach: I'm glad you committed the patch from #21, but it should actually have been a separate issue, as it's unrelated to this one here. I had reopened this issue after tracking down some breakage in field-conditional-states that turned out to be a complicated mix of your commit here and some fixes that happened in the core states.js *after* this commit.

My patch in #8 effectively re-creates the changes you committed here but based off the latest version of states.js from core, and everything works nicely (for a whole bunch of people who commented on my patch). Perhaps this should have been dealt with as a separate issue as well, but because it was related to this issue on this project, I figured it would keep things in context to post it here.

How would you suggest we address this? It's clear to me that this patch is useful to lots of folks here, and it'd be great to have it committed on jquery_update, although I know it's been suggested to fix this in core instead- the tricky thing with that is the particular bug doesn't seem to show up for core states.js, since it's working with an older version of jquery. Thoughts? I'm happy to do whatever I can to help resolve this for good :)

Thanks!
Derek

We could push your patch at #8 up. Didn't realize that was the one we were looking for. Thoughts?

@RobLoach: that sounds like a great solution to me :)

Patch in #8 appears to fix this issue #2013210: FAPI #states: Fix conditionals to allow OR and XOR constructions, however I'm running into a problem now with jquery selectors containing an array, specifically after an ajax callback. For example, I have a textfield with this visible state:

'#states' => array(
  'visible' => array(
    ':input[name="checkbox"]' => array('value' => 1),
    ':input[name="fieldset[status][0]"]' => array('value' => 1),
  ),
)

After running an ajax callback (that adds a new field for my purposes), the above textfield loses its visible state because it's not picking up the jquery selector containing the array (ie. fieldset[status][0]). It was working before I applied the patch in #8. Can someone please confirm this problem.

Please review #2018791: states.js is not compatible with jquery +1.6.1 because it use $.attr in the wrong way so we can simply remove states.js from this module, this will also fix a lot of other bugs.

Yeah! thanks!! #8 worked like I wanted! thanks! now the OR works fine :)

Cheers!

applying patches had no effect until I disabled field_conditional_state module (the cause of my problems !). Work great now.

Yes was fixed upstream :) Took months but it will be available on the next drupal release #2018791: states.js is not compatible with jquery +1.6.1 because it use $.attr in the wrong way

@ericduran So now we can remove states.js!

Ok drupal 7.26 is out :). Time to remove all the related code from jquery Update. Let's se if I can provide a patch soon.

We will need to requiere this version.

Let's se if I can provide a patch soon.

That would be really great, because this issue can't be fixed, until this issue is fixed.

Thank you gagarine, that you try to solve the problem.

Try out https://drupal.org/project/field_conditional_state, please. The older project is going to be discontinued and the new 2.x one uses core js only.

Thanks for the information hass. How stable is the module at the moment? It seems to be in a very early stage of development. I guess it can't be used in a productive drupal installation yet, without a high risk of damages. What do you think?

As I know DEV is much more stable than final 1.x and close to final.

Here's a patch that removes states.js and its reference from the module. Doesn't worry about Drupal versions.

Did you want to include a programmatic test for Drupal version, or a dependency in the .info file?

FYI the patch in #43 does work and seems to resolve several of the states.js issues I've run into. HOWEVER it also causes a lot of modules and jQuery code to stop working properly, as the .browser method was removed from jQuery v1.9+ and as a result, I have pages throwing javascript errors left and right.

Just a warning for anyone if they are applying it, it's a good patch, but thoroughly test your javascript afterwards!

#43 works well and fixes a lot of issues. Please commit and do not forget to remove the misc/1.7 folder. It looks like this cannot be done with a patch.

#43 works well and fixes a lot of issues!++

Thanks patch #42 fixed it for me :)

I've found a problem with the jquery_update states.js and Ajax that the core one does not have. Applying this patch solved the issue. Let's do this!

Rtbc++

@tstoeckler, what was the additional problem?

I had a problem with an addressfield field (https://drupal.org/project/addressfield) when I wanted to conditionally show a field depending on the value of the country element. The changing of that element triggers an AJAX request.

I applied the patch and found some reference to states.js.

A switch to include or not seem useless as the one from drupal should work with all version now.

I will do a patch ASAP.

#43 doesn't entirely work for all versions.

I was using jquery with addressfield.
I set jquery to 1.7
Drupal 7.26
When I applied the patch I get the following error:

Uncaught Error: Syntax error, unrecognized expression: # jquery.min.js?v=1.7.1:3
m.error jquery.min.js?v=1.7.1:3
m.filter jquery.min.js?v=1.7.1:3
m jquery.min.js?v=1.7.1:3
c.querySelectorAll.m jquery.min.js?v=1.7.1:3
f.fn.extend.find jquery.min.js?v=1.7.1:3
Drupal.behaviors.states.attach states.js?v=7.26:23
(anonymous function) drupal.js?n2m3ce:76
e.extend.each jquery.min.js?v=1.7.1:2
Drupal.attachBehaviors drupal.js?n2m3ce:74
(anonymous function) drupal.js?n2m3ce:412
n jquery.min.js?v=1.7.1:2
o.fireWith jquery.min.js?v=1.7.1:2
e.extend.ready jquery.min.js?v=1.7.1:2
c.addEventListener.B

--
Uncaught TypeError: object is not a function VM1385:16
(anonymous function) VM1385:16
Zf.main %7Bmain,geometry,places%7D.js:52
(anonymous function) %7Bmain,geometry,places%7D.js:25
(anonymous function) %7Bmain,geometry,places%7D.js:12
(anonymous function) %7Bmain,geometry,places%7D.js:25
M %7Bmain,geometry,places%7D.js:11
(anonymous function) %7Bmain,geometry,places%7D.js:25
Vf.(anonymous function).bf %7Bmain,geometry,places%7D.js:24
Wf.(anonymous function).Xc %7Bmain,geometry,places%7D.js:25
$f %7Bmain,geometry,places%7D.js:25
(anonymous function)

Than, addressfield need to be fixed.

I needed a version of this patch that applied to 7.x-2.3, so in case anyone else needs it too, here it is.

If you've come here because you still have this issue, install the 7.x-3.x branch and enable jQuery Migrate as stated in comment #5 at #2555403-5: FAPI #states "checked" use prop method in place of attr