jQuery update breaks AHAH form when there is a file input (file upload) in the form

You do not replace files in /misc. Just install and enable jQuery Update. In the replace folder there is an ahah.js that works.

I've just been debuging #860966: Create Content - Book Outline - Book: Select Drop Down AHAH form does not show Parent Item and I tracked it down to this:

modules/jquery_update/replace/ahah.js line 121:

$(this.element).addClass('progress-disabled').attr('disabled', true);

Disables the element that triggered the post, resulting in that element being removed from the post entirely. Apparently this changed in jquery between the version in Drupal 6 and the version in jquery_update, as the same line is also in the ahah.js of Drupal 6.

Commenting out that one line makes the book form function just fine again, and I suspect it will also fix this issue. Did the order of things change? (first post, then disable?)

You do not replace files in /misc. Just install and enable jQuery Update. In the replace folder there is an ahah.js that works.

I can confirm this issue even without replacing the files

It's a critical issue -- what to do? Use stable ver?

You can try to see if my suggestion of removing that one line fixes the problem for you. If it does it's a good lead for the maintainers as to what the problem really is.

Thanks, Hylke! Looks like that 'fixes' it.

I was experiencing this issue too when using my module AHAH Dependent Fields.

Took me half a day to locate the bug to this module and its ahah.js.

Commenting the line mentioned in #3 fixes it for me.

[Changing this to a bug report as it does break other modules just by installing this module]

After a bit more research the issue seems to be caused by a change in jquery.form.js which now no longer submits fields that are disabled

Looking at Drupal 7, it seems to use the beforeSend event instead of beforeSubmit. I tried D7's approach with this module along with the latest jquery.form.js, but it still exhibited the problem.

So for now here is a patch with the element disabling removed.

And here is an alternative patch to #9 - this one swaps the disabling of the element with a read only setting. This works and at least on some form element types prevents editing.

I ran into this issue with a custom module for a site I'm working on. According to the HTML specs, disabled elements shouldn't be submitted, so likely the older jQuery or jQuery.form shipped with Drupal 6 is breaking spec. Strangely, it looks like it was Firefox's .submit() method that was actually ignoring the element, not any of the JavaScript up to that point.

I've attached a patch that hides the element instead of disabling it.

Tested #11 and all bugs with AHAH calls I had are completely gone now.
This is a critical bug as it breaks sites and admin forms, therefor marking it as critical.

Thanx more than a bollion deviantintegral... this bug was killing me! And it being Blue Monday I couldn't handle much more :)

Cheers

I have run into some issues with patch #10, which can cause the 'Add more' button not to function correctly.

Patch #11 does work fine, and seems to be the way to go here. Ideally i'd prefer not to have hide the element, as it can be confusing in the UI, but its better to do this i feel than leaving it visible and active.

Completely missed the patches by smoothify - yay cross posting.

The worst part about what I've done in #11 is where we had some inline select boxes. I ended up setting min-width based on the actual width of the element (since that depends on font and browser). Works with any decent browser and IE7+. So, there are display issues with hiding the element, but at least you can submit the freaking form. I think it's probably best to use this approach but also document it as this could mess with all kinds of other modules.

/**
 * Force a minimum width of a country field so that inline state fields
 * don't jump around on the page.
 */
Drupal.behaviors.mymoduleCountryWidth = function(context) {
  $('.mymodule-country:not(.mymodule-country-width-processed)', context).each(function() {
    $(this).addClass('mymodule-country-width-processed');
    $(this).css('min-width', $(this).width());
  });
};

I ran into this last night using the 1.1 version when I saw the throbber spinning round and round when I tried to delete a file I'd uploaded, and of course thought it was something I had done elsewhere (I had hacked up transliteration a bit lol), but finally tracked it all down to here, too (which I have hacked up to go to microsoft and/or google for the file instead of locally, but that's another story). Anyways, my quick fix back in the day was to just update jquery on non admin pages, but now I see I have to do it on edits and adds as well. So, my new quick fix is to add "if(arg(0)=='admin' || arg(1)=='add' || arg(2)=='edit') return;" to the beginning of jquery_update_preprocess_page() which I am sure will bite me down the road again, too :)

Jim

EDIT:

of course, upgrading to the 6.x-2.0-alpha1 version just now fixed everything without any of those bite you in you know where hacks I mentioned above...silly me.

Fixing the version of this issue. If needed, we can get this backported to 1.1 after it's committed.

I also ran into the inline fields issue with patch #11 - this can be common when using multiple fields since that uses inline-block as a display style, which with this patch gets swapped for display: block when the show function is called.

I haven't used D7 much, but I know it still uses the disable method we are trying to avoid. Curious, I looked into the POST response that is fired, I notice that it also sends the following two post values with the response - 'triggering_element_name' & '_triggering_element_value' - This does of course go much further into the new ajax system of D7 and out of the scope of jquery_update.

Thanks a ton..!!

This worked for me...
We were trying to fix this since a few days...

Updating to the jquery_update alpha 6.x.2 served our purpose.

Hope this doesn't break anywhere else.

Here is an experimental patch for this problem:

This patch keeps the disabled behaviour of the element and instead creates a hidden input with the the correct name and value so the correct data gets submitted as usual. The hidden input is removed once the submit is complete.

So far its working for me with buttons, text & select elements, and avoids the UI moving around as in patch #11.

Sorry, finishing up the website for presentation. don't have the time to test your latest patch. Can only confirm that the patch in #11 by deviantintegral works for me.

Cheers

I tested #19, and it breaks when you have a select with an empty value in #options:

<?php
'#required' => TRUE,
'#options' => array(
  '' => t('Select country'),
  '0' => t('United States'),
  '1' => t('Canada'),
),

Once you select a non-empty value, and then select the empty value again, #ahah breaks entirely and the form never changes.

patch #19 worked fine for me.

@ #21: is it a good idea to use an empty key, and a zero key?

patch #19 worked for me. I can now upload images in safari via cck imagefield. Finally :) Thank you
I still see this error in my console inside Safari's Web Development:

TypeError: Result of expression '(jQuery(this).data('form-plugin-onload'))' [undefined] is not a function.

But it still works.

Using an empty key is the only way to have a #required selection dropdown, where the user has to make a choice. As for using zero as a key, it doesn't have any affect one way or another on the patch, and is pretty common though normally used in the numeric, and not string form as in my example.

Comment #3 worked for me, but I ran into problems with my custom CCK field.

I followed this tutorial to create a "compound field", where each field has multiple sub-fields (see attached screenshot):

http://www.poplarware.com/articles/cck_field_module

My CCK field has several sub-fields including an AHAH-enabled select box. Unfortunately, after installing Jquery Update and upgrading to Jquery 1.3, the select box values were no longer being passed to my AHAH callback function (because ahah.js disables the select box until the request has finished). So, my sub-fields were not being dynamically populated.

Instead of commenting out line 121 of ahah.js, I wrapped it in an if statement, so that only "submit" elements will be disabled:

if ($(this.element).hasClass('form-submit')) {
  $(this.element).addClass('progress-disabled').attr('disabled', true);
}

I hope this helps someone!

I went to try and fix the issue I mentioned earlier, but I can't replicate it anymore. So, I say #19 should be committed and we can do a followup issue if needed.

Just been tackling this issue myself and agree the patch in comment #19 worked a treat. Should be committed.

Subscribing - was about to put colorbox on a 6 site and need jquery_update 2 but not sure if should until this patch is committed?

Subscribing - Six dev still doesn't fix it. Would use jquery_update for the drupalchat module.

I am also having this problem... cck file uploads are broken when Jquery Update is enabled. However, patch #19 or upgrading to the latest dev has not fixed it for me.

I'm still using the jquery update version alpha but when i use a file field i can't invoke ahah. I've tried the patches above but they don't dix the problem. any idea please? I'm getting frustrated

Framework does no longer fire automatic previews with JQuery update.
http://drupal.org/node/688538

Just replacing provided jquery.form.js by the last one from github (https://github.com/malsup/form) solved this issue for me.

and solved my problem too
thx :)

Patching ahah.js by following patch #19 here fixed my custom ahah form text field not keeping its values unless the form file field had been uploaded first.
Similar conflicts were occurring with CCK imagefield and CCK filefield. This patch to ahah.js seems to help with all of them.

I have also updated my callback to use drupal_to_js instead of drupal_json when printing the callback status and data but this didnt seem to make a differene:
http://drupal.org/node/399676#comment-1438662

I can confirm that using updated jquery.form.js (3.03 - 08-MAR-2012) as suggested by Yoran in comment #33, fix the problem.

(I'm using version = "6.x-2.0-alpha1+7-dev" and jquery 1.7)

#33 worked for me as well. Rolling a patch.

The patch for #37 worked for me but I am little unsure how the new js code should be formatted. For example the existing code has some line breaks and the patch does not.

I think one of maintainers will have chime in on how the JS code should be compressed and formatted.

BTW, the patch fixed this issue #860966: Create Content - Book Outline - Book: Select Drop Down AHAH form does not show Parent Item but I am not sure if it might break something else.

So I did a diff of the jquery.form-2.43 and jquery.form-3.09.js can see that the changes between the 2 versions is so great that it is too risky to update jquery.form.js to a new version.

Patch #19 is the safest fix and should probably be committed.

#33 solved my issue. Thanks.

#33 works for me, pressflow 6.25

Replacing the jquery.form.js in replace folder of jquery_update module worked perfect as mentioned in #33
Thanks a lot as saved my life :)

#33 worked for me too. Just upgrade to a newer version of jquery.form.js. Here is a patch to do that for version 3.04.

Latest patch in comment #43 is working for me on two seperate sites!

Latest patch in comment #43 solved the problem for me too.

After installing jQuery update 6.x-2.0-alpha1 some AHAH forms of mine got broken.
It seems that when form submission is triggered by AHAH checkbox of dropdown menu or something like that the triggering element retains it's old value, because the element being disabled on preSubmit step. Updating jquery.form.js to version 3.17 - last one compatible with jQuery 1.3.2 solved the problem for me. Got it here https://github.com/malsup/form/tree/16022a3171f858845c877db3a74362f3d193... don't know if there is a better way to obtain it :-)

The patch on #43 fixed this for all browsers including latest Chrome, Firefox, IE8 and IE10 - but NOT for IE9. I tried using jquery.form.js version 3.17 per @curlymike's comment in #46, but it didn't fix the problem unfortunately. Everything is working but IE9!

Anyone know where to obtain jQuery Form Plugin V3.04 these days?

E

@aitala it's part of the patch in #43

@rv0 - I see that now, but that did not work. I reverted to an earlier version of the module which has solved the problem.

Thanks,

E

Drupal 6 reached EOL (end-of-life) on February 24, 2016.