setting class 'use-ajax-submit' for form submission causes js error(s)

Subscribing. Setting to needs review so it gets tested. However, we have no test coverage for this, of course :-)

As part of the CTools upgrade, we discovered that this AJAX path has never been used. A bunch of minor changes are required for CTools to utilize its typical javascript paths, including some prevention from multiple submits while waiting and using a try { } catch { } block and making sure the proper values are set.

The use-ajax-submit is comfirmed completely broken as described in the original issue here.

I can't get it to work rationally with either #1 or #3 though. With #3, my form submits and the animation continues forever, leaving the page in a broken state.

Attached is a super-simple test module to demonstrate use-ajax-submit.

critical? no..

Really? A crash bug isn't critical?

It's a crash bug. crash bugs are critical, IMO.

Also and maybe this is egotistical, CTools needs it.

Marked #918812: Ajax.inc attach behavior broken for submit buttons, typos and missing properties as a duplicate.

since my other issue got closed even though it had a valid patch in it
#918812: Ajax.inc attach behavior broken for submit buttons, typos and missing properties

here's the patch from that issue.

there are other typos and full missing lines of code in that block.

Both of the changes in #10 were already done in the patch we're working with in #3. #3 is the "live one"

Setting back to "needs work". And really, I (or someone before me) just needs to get this boiled down into a tiny test/demonstration environment.

@alex_b: Saw your ping - sorry couldn't respond.

The reason we need some demonstration code:

1. The patch is #3, not #10. Larger than 2 lines.

2. We *must have* either demonstration code or valid tests (probably both for javascript-related stuff) for every issue. The reason this stupidity got in here is that the code had never been executed. Let's not have code in core that has never been executed any more. Now that #789186: Improve drupalPostAJAX() to be used more easily, leading to better AJAX test coverage has gone in, we *may* be able to write a valid test, which would be great. But IMO a piece of UI code which has no live demonstration in existence is no code at all.

-Randy

I tested this using the drupal 7 port of the boxes module hosted here -
github.com/vertice/boxes

along the ctools from here :
github.com/developmentseed/ctools

the patch from #3 definitely resolves the issue.

here is the working version of your demo module.

the reason no working code for this ever existed is because it has been a broken and dead/unused code path for a very long time indeed.

The reason it was broken is primarily that it is a code path that came from CTools when the AJAX framework was installed.

There is clearly a bug when there is an AJAX error (which is why the submit button died). I suspect my unsetting .ajaxing in complete is wrong. I have not had a chance to revisit this since the sprint (sorry, it's been that kind of week) but this is very important to me so I assure you that I will. Right now the CTools D7 work is dependent upon this patch (and the lazy-loading patch).

It's possible we could split this patch up into two, because part of the patch (the double-click prevention) is separate from restoring the use-ajax-submit pathway and making it actually work. I'm not sure I want to do that since two patches are harder to get in that one, and the double-click prevention is, IMO, a critical bugfix in and of itself. =)

I think the first part (my patch) could be considered it's own thing.

it's just fixing 2 typos, one of which is a compile time error(!) , and adding a missing line present in all the other blocks in that function.

Committed to CVS HEAD. Happy birthday, Earl. ;-)

hi

i got this error . when ever click on submit button.

An error occurred while attempting to process /detracs/use_ajax_submit: ajax.form.ajaxSubmit is not a function

Thanks

That would indicate that the code using it did not do:

drupal_add_js('misc/jquery.form.js');

+++ misc/ajax.js	15 Sep 2010 19:35:54 -0000
@@ -55,7 +55,13 @@ Drupal.behaviors.AJAX = {
+      element_settings.progress = { 'type': 'throbber' };

Is type a reserved token?

+++ misc/ajax.js	15 Sep 2010 19:35:54 -0000
@@ -98,7 +104,9 @@ Drupal.ajax = function (base, element, e
-    submit: {}
+    submit: {
+      'js': true
+    }

This looks a bit odd to me. Elsewhere, the AJAX framework is using _triggering_element* POST data to identify and specially handle AJAX submissions. Since this key/value pair is not used anywhere, this change at least deserves a code comment.

+++ misc/ajax.js	15 Sep 2010 19:35:54 -0000
@@ -147,21 +157,30 @@ Drupal.ajax = function (base, element, e
+        ajax.form.ajaxSubmit(options);     ¶

Trailing white-space.

Powered by Dreditor.

This looks a bit odd to me. Elsewhere, the AJAX framework is using _triggering_element* POST data

A what? I know that in most cases I've advocated using url mangling (i.e, nojs/ajax) to handle this, but there are times when doing that is not convenient so having a $_POST identifier is what I was going for. I'm not sure what _triggering_element means in this case.

Is type a reserved token?

Don't look at me. The 'progress' object is used by the ajax object to determine what progress bar to show. I was simply making the throbber the default because on the submit buttons, using the more complex "Loading" progressbar pushes sibling buttons all over the place in a way that is unattractive. The throbber is actually only slightly better but I figure I can clean it up with CSS in my forms. That's always been a bit of a visual problem that I haven't had good solutions for.

#21: drupal.ajax-use-submit.21.patch queued for re-testing.

Attached patch is what remains. Other parts were cleaned up through other patches already.

1) Processing code for Drupal.settings.ajax also uses some uncommon way to process each item. Fixed in attached patch.

2) None of the jQuery selectors in Drupal.behaviors.AJAX takes the context into account. Fixed in attached patch.

+++ misc/ajax.js	6 Nov 2010 19:57:57 -0000
@@ -22,20 +22,18 @@ Drupal.behaviors.AJAX = {
+      $('#' + base, context).once('ajax', function () {
         var element_settings = settings.ajax[base];
 
         $(element_settings.selector).each(function () {
           element_settings.element = this;
           Drupal.ajax[base] = new Drupal.ajax(base, this, element_settings);
         });
+      });

Somehow, neither the old nor the slightly improved code makes really sense to me.

The actual elements to ajaxify are denoted in

settings.ajax[base].selector

But we are turning base into an HTML ID (i.e., #base) and testing whether we already processed that element.

So if base is not identical to .selector, that check will fail, and we're processing the elements more than once.

Additionally, this current code effectively selects the elements twice -- i.e., once for #base, and once again for .selector.

Was there any undocumented reason for doing it that way, or is this just a bug?

Powered by Dreditor.

@merlinofchaos: Any feedback on #27? The current code looks a bit broken to me. It technically means that AJAX events are potentially bound multiple times on elements in edge-cases (primary prerequisite: existing ajaxified content is not removed from the page, and a subsequent AJAX request uses a selector that happens to select previously ajaxified elements).

Feedback, anyone?

Additionally, #951262: Move #ajax default settings from PHP into JS needs a confirmation, too. The patch helps us to attach AJAX events on the actual #ajax .selector.

Incorporated the relevant line from #951262: Move #ajax default settings from PHP into JS

However, the @todo I added in this patch leaves me in the dark. Evaluating the current code in HEAD,

1. we do not apply AJAX events if the #base does not exist on the page (even if .selector may exist).
2. #base is not actually used for many AJAX commands; .selector is used instead.
3. Drupal.ajax[base] is always overwritten with the AJAX instance of the element that matched .selector last.

Any clues, anyone?

Re-rolled for #951262: Move #ajax default settings from PHP into JS

@merlinofchaos: Would love to discuss the @todo in this patch with you.

Alright, discussed with @merlinofchaos in IRC, and the proper fix is to make Drupal.ajax() support multiple elements (and therefore only binding once on all matched elements), while still ensuring backwards-compatibility.

Attached patch changes the element argument to $elements (a jQuery object), and ensures that potentially existing code does not break when passing a DOM node.

The patch is a bit larger, since during reviewing where ajax.element is currently used, I got confused since a couple of handlers are still using this instead of ajax, so I changed that to be consistent.

Has to go into 8.x first.

Hi.

I've been experiencing serious problems with ajax in D7.

I can not edit or create views. I also have problems with panels.

When I try to edit, create, view, or simply close a window of the views module, I get the following message:

An error occurred while attempting to process /drupal/admin/structure/views/view/articles/preview/default/ajax: 'ajax.form.ajaxSubmit' is not a function

In a way, my site is down. I wonder if my problems are related to the issue discussed here and if anyone can help me, pointing to a solution, because I'm not finding the problem nor the solution. If so, I will open a new issue.

Thank you.

@astutonet, you need to open a new support issue, or post to a good support location like http://drupal.stackexchange.com.

The first thing to do is to see if you can recreate the problem on a very simple Drupal install (with views). Then you can begin debugging. It's most likely another module. You should also make sure you have the latest of everything. Some debugging hints are at http://randyfay.com/debugging.

@rfay, I will try to reproduce the problem through a new installation, but I think it will be difficult because the site in question is an updated version of a site originally created with the D6, therefore, was born with its own content.

Even though I can not reproduce the error, I will create a new issue and report here.

Tks.

Edit:The new issue about #34 is here: http://drupal.org/node/1380370

#32: drupal.ajax-selector-once.32.patch queued for re-testing.