Many sites now use various means to update their version of jQuery to a later version than 1.4, the version in Drupal 7.

jQuery deprecated (version 1.6) and removed (version 1.9) the use of .attr() for use to set "checked" and "disabled" properties. It also points out that attempting to retrieve values by using .attr() will result in confusion/problems, as in this example: $elem.attr("checked"); will return true if $elem has a "checked" property at all, not if it is true.

jQuery now uses .prop() instead to set and retrieve the value of a "checked" or "disabled" properties of a node.

.removeAttr() may also cause problems/unexpected behavior, as it completely removes the property rather than setting it to false, consequently it will no longer be selectable by selectors that typically would work. 
Example: 
Using <code>jQuery('input[name="test"]').removeAttr('checked');

on <input name="test" type="checkbox" checked="true" /> will result in <input name="test" type="checkbox" />. This is typically not the intended result, as it will cause CSS and jQuery selectors that you would expect to be able to find that item to fail.
Example: jQuery('input[checked]') will now fail to return this node.

See: jQuery 1.9 Upgrade Guide: attr vs. prop

It looks like the jQuery Update module's newest dev branch (7.x-3.x-dev) is including an option via a patch for using jQuery Migrate, which fixes compatibility with legacy jQuery code in newer version of jQuery. However, since most users will not move to that branch until it is out of dev, either a dependency on certain versions of jQuery and possibly certain settings in jQuery update need to be addressed, or the code in question should be made to work with all versions of jQuery.

There seem to be a few ways of going about solving this:

  1. Detect the version of jQuery in use and use code that works with that, this seems like it would add a lot of code doing the same thing, but for different versions of jQuery - YUCK!
  2. Force a full dependency on the jQuery update module and and a >X version of jQuery and update all code to use the newer version
  3. If using the jQuery update module, require the 3.x branch, as it includes jQuery migrate - not sure if feasible or possible to have a module somewhat dependent...
  4. Include the jQuery migrate plugin if the detected version of jQuery is not the expected one from original core and the migrate plugin isn't already included

My first inclination is that #4 sounds the most feasible.

There could be additional options or combinations of these that are better, I am just trying to help the discussion get started and once we have a viable solution, potentially help roll patches.

possible problems:

file: services/js/services.admin.js

  1. Line 53: $(groupCheckbox).attr('checked', (methodCheckboxes.filter('[checked]').length == methodCheckboxes.length));
  2. Line 58: methodCheckboxes.attr('checked', $(this).attr('checked'));
  3. Line 58: methodCheckboxes.attr('checked', $(this).attr('checked'));

Comments

marcingy’s picture

Category: Bug report » Feature request

The module only supports what ships with drupal core so this isn't a bug, but more than welcome to accept a patch.

Option 1 see option 3 this might not be too bad just means moving logic from hook requirements and won't break any installs.

Option 2 is a no go we can't have a hard requirement on jquery update.

Option 3 could actually work if we do it as part of hook_requirements. So query if module_exists() and then if it does do a call to https://api.drupal.org/api/drupal/modules%21system%21system.module/funct... and see what version of the module we have.

Option 4 I'd rather not maintain code that isn't really related to this project.

So option 1 or 3 seems best where option 1 is actually a more graceful version of option 3. We could actually move Drupal.behaviors.resourceMenuCollapse into its own js, so only Drupal.behaviors.resourceSelectAll would need separate versions.

DrCord’s picture

If we do option #3, we wouldn't need to change the code, just require that the option for jQuery migrate is turned on, which would then make all the old code work...

marcingy’s picture

Ok lets go for option 3...roll away :) I am not a front end person at all but will happily review

DrCord’s picture

It may take me a while to be able to roll a patch for this, as I am super busy...sorry :( I will do what I can when I can, as soon as I can :D

DrCord’s picture

I was thinking about implementing option #3:

Once we determine that they have the jQuery update module 3.x branch with the jQuery migrate option, how do we force them to have the option to use the jQuery migrate plugin turned on...?

kylebrowning’s picture

Status: Active » Closed (won't fix)

Cleaning issue queue, if you want to work on this, re-open the ticket.