Improve compability with autocomplete and attachBehaviour improvements

Thanks for your ideas. Can you post this as a patch? http://drupal.org/node/707484

Thanks, Eugene! I'll admit that my javascript isn't super strong to be able to say whether and how this version is an improvement. I'll ask in #drupal-contribute to see if I can get some reviews.

If anyone else who uses hide_submit 7.x-2.x could review this patch it would be a great help.

+++ b/hide_submit.jsundefined
@@ -2,47 +2,51 @@
+    $('form', context).once('hideSubmitButton', function () {
+      ¶
+      $(this).each(function (i) {

Trailing whitespace

+++ b/hide_submit.jsundefined
@@ -2,47 +2,51 @@
+          ¶
+          return true;
+        }  ¶
+      });

Trailing whitespace

Replacing $('form'). with $('form', context) is definitely needed. Otherwise you get a ton of "progress" messages when submitting a form if some AJAX actions were fired off on the page.

Patch for my recommendation..

I'll have a look on how to merge this with #1378110: Javascript cleanup: Conflict w/ clientsidevalidation, compatibility w/ autocomplete & attachBehaviour, show button again

See patch in #1378110-13: Javascript cleanup: Conflict w/ clientsidevalidation, compatibility w/ autocomplete & attachBehaviour, show button again, marking this as duplicate.

I don't see how this is a duplicate.

The other issue relates to users being unable to resubmit the form after clientside validation fails. This issue is about the submit button being hidden by autocomplete widget events before a form submission has even occurred.

To reiterate, the problem here is that when you're typing into an autocomplete field and you press the return key to make a selection from the available options, the form's submit button gets hidden even though no form submission has been made. This means you then can't submit the form at all.

I've just tested out the latest dev release which includes the patch from #1378110: Javascript cleanup: Conflict w/ clientsidevalidation, compatibility w/ autocomplete & attachBehaviour, show button again and this problem still occurs. The fact that the submit button now gets unhidden again after a few seconds isn't really an acceptable solution because the user is still prevented from submitting the form for an arbitrary amount of time.

Does this help?

No, that doesn't appear to make any difference.

I applied the change, cleared the caches and tested again, but the submit button still disappears when you press the return key on an autocomplete suggestion.

I'm attempting to figure out a fix myself but unfortunately my javascript knowledge is extremely basic.

#10 In what browser are you testing this? I'm unable to reproduce this :/

The autocomplete doesn't submit the form, it uses GET to. Older versions of IE used to do a form submit when you pressed enter, but if that's the case, it would also do on a non autocomplete field.

I'm seeing this behaviour in Firefox and Chrome. I haven't tested it in other browsers.

I don't believe you're entirely correct in saying that autocomplete doesn't submit the form. The submit event does get fired, but autocomplete.js simply handles the submit event and prevents the submission if the suggestions popup is visible.

hide_submit.js just acts on the submit event and therefore hides the submit button regardless of whether autocomplete prevents the submission or not.

Something like this seems to fix the problem me, but I have no idea if it's good code:

var autocompleteSubmit = ($.isFunction(Drupal.autocompleteSubmit)) ? Drupal.autocompleteSubmit() : true;
if (!e.isPropagationStopped() && autocompleteSubmit) {
 ...
}

Yes and no, the search uses get to retrieve the possible values, the behavior adds a submit, but that is to avoid that people can submit the form will the popup with suggestions is open.

Autocomplete never issues a submit on a form, so the submit is triggered by the enter, I assume you only have one submit button on your form?

Well, I'm using a fresh Drupal installation and I'm just testing this on the node creation form with taxonomy and entity reference fields using autocomplete widgets. There are the usual "submit" and "preview" buttons and that's it.

Anyway, reading the jQuery documentation some more, I infer that Drupal.autocompleteSubmit() returning false should cause e.isPropagationStopped() to be true, but in my case e.isPropagationStopped() is false when the return key is pressed on the autocomplete suggestions, so I guess the problem is that the submit handler in hide_submit.js is being evaluated before the one in autocomplete.js?

Edit: Yes, I checked the execution order of the submit handlers and hide_submit is processed before autocomplete, at least on my test system. Perhaps your browser isn't firing submit events when you press the return key because you're on a different operating system? I'm testing on Windows here...

A simpler solution might be:

if (!e.isPropagationStopped() && $('#autocomplete').length == 0) {
  ...
}

I tested on windows 7, ie 9 and chrome 24, and on ubuntu 12.04 using chrome, the enter never triggers a form submit.

While the patch in #16 probably will work, it creates a dependency on autocomplete which should be avoided, what is strange is that it is before the autocomplete, can you check the order of your javascript files in the html source? Or can you add a breakpoint in the javascript in both behaviors to see which one is loaded first?

This issue spans two issues:
1) context is not being used correctly - so the behavior of this module gets attached for each AJAX call invoked on the page.
2) Enter (within an autocomplete) hides the button.

My last patch covers #1 - which seems to have been fixed in the other issue mentioned.

I'm on Windows XP rather than Windows 7, but it seems unlikely that that would be what's triggering the form submit event in my testing. I don't know what to say really...

Here's the script order in the HTML <head>:

<script src="http://localhost/hide_submit_test/misc/jquery.js?v=1.4.4" type="text/javascript">
<script src="http://localhost/hide_submit_test/misc/jquery.once.js?v=1.2" type="text/javascript">
<script src="http://localhost/hide_submit_test/misc/drupal.js?mjjxhy" type="text/javascript">
<script src="http://localhost/hide_submit_test/misc/vertical-tabs.js?v=1.0" type="text/javascript">
<script src="http://localhost/hide_submit_test/misc/form.js?v=7.21" type="text/javascript">
<script src="http://localhost/hide_submit_test/sites/all/modules/hide_submit/hide_submit.js?mjjxhy" type="text/javascript">
<script src="http://localhost/hide_submit_test/misc/textarea.js?v=7.21" type="text/javascript">
<script src="http://localhost/hide_submit_test/modules/field/modules/text/text.js?mjjxhy" type="text/javascript">
<script src="http://localhost/hide_submit_test/modules/filter/filter.js?mjjxhy" type="text/javascript">
<script src="http://localhost/hide_submit_test/misc/autocomplete.js?v=7.21" type="text/javascript">

As you can see, autocomplete.js is the very last script to be loaded, while hide_submit.js is roughly in the middle.

I also did a console.log($('form').data('events')) in Firebug and inspected the object, which similarly shows hide_submit's handler at index 0 and autocomplete's handler at index 1 in the binding order.

I don't quite follow this though:

While the patch in #16 probably will work, it creates a dependency on autocomplete which should be avoided

Can you really call it a dependency? It doesn't make autocomplete required and no error is generated if autocomplete is absent. It's simply testing for the existence of an element in the page. But hey, I'm at the limit of my javascript skills here so I'll leave it to the experts ;)

Ok, how about this patch.

You can apparently set a weight option in drupal_add_js() which allows us to force hide_submit.js to be loaded after autocomplete.js.

This results in e.isPropagationStopped() correctly detecting that autocomplete has prevented the form submission.

As an alternative, setting the module weight higher should supposedly achieve the same result.

Yep, was thinking the same, something about great minds thinking a like ;-)

Patch looks good!

I created a follow up issue to optimize it, but best to commit this patch asap, #1941592: Get rid of hook_init to improve performance

Thanks for the patch and reviews!

Now committed http://drupalcode.org/project/hide_submit.git/commit/0b65213