ENTER in autocomplete widget disables tinymce

You didn't explicitly state it, but I'm assuming the editor is not on the auto-complete field itself. ;)
If anything triggers the onSubmit handlers, Wysiwyg will detach the editor. Most editors also listen to the event internally, but that usually just causes a synchronization to the original textarea, leaving the editor active. I have not looked at how jQuery treats multiple onsubmit handlers, or how the AW module does its thing yet so I'm not sure exactly what happens but I can take a guess. OnSubmit handlers have the power to stop forms from submitting simply by returning false, which I assume AW uses, and if jQuery keeps executing these handlers until one of them returns false (or there are no more), it looks like Wysiwyg module's handler runs before AW's. Fixing a race condition like that between modules might not be easy... worst case; let AW override Drupal.wysiwygDetach and add a check for 'AW-is-about-to-cancel-this-submit-event'-flag.

Will know more once I get time to dig into AW.

Autocomplete Widgets uses #autocomplete_path for its fields. This functionality is implemented in Core's misc/autocomplete.js, so it will always run before our onSubmit handler. It simply prevents the form from submitting if the suggestions popup exists, so I made wysiwyg.js look for it too.

I haven't tested this patch much since I don't have an installation using autocomplete fields but this patch should work nicely.

This smells like a bug in Drupal core. All .submit() handlers should be properly intercepted when submitting a form via ENTER.

Core could stop the other event handlers added via jQuery from running by calling event.stopImmediatePropagation, but it was not added until jQuery 1.3 and D6 uses 1.2.6.

Returning false from the autocomplete handler will only prevent the default action from happening (browser making the request) and the event bubbling to elements above the current element. Since all the submit handlers are attached to the form element, they will still be executed. event.isDefaultPrevented() was also not added until 1.3 so that doesn't help us.

Patch #2 (by hand) works for recommended release 6.x-2.1 too. Thanks.

So we should quickly create a patch for core, as it's using 1.4 now? :)

@sun, in D7 we can use event.isDefaultPrevented to know if autocomplete's submit handler returned false so I wouldn't consider it a major issue there.

I have this problem with TinyMCE disappearing. I tried the patch i #2 but it didn't work for me (using 6.x-2.1). I did it manually, but I think I applied it correct.

When using the patch in #2 I get

format is not defined
Drupal.wysiwygDetach(context, params[format]); 

when previewing a comment Im about to post.

An other strange thing is that Drupal.wysiwygDetach´s second argument must be an object (See params.field) and as far as I can see " params[format]" will not be an object, right?

Drupal.wysiwygDetach = function(context, params) {
  var editor = Drupal.wysiwyg.instances[params.field].editor;
  if (jQuery.isFunction(Drupal.wysiwyg.editor.detach[editor])) {
    Drupal.wysiwyg.editor.detach[editor](context, params);
  }
};

This patch works for me

// Detach any editor when the containing form is submitted.
    $('#' + params.field).parents('form').submit(function () {
      // Prevent detaching if the suggestion popup from misc/autocomplete.js
      // exists because the form will not be submitted.
      if($('#autocomplete').size() == 0) {
        Drupal.wysiwygDetach(context, params);
      }
    });

but Im not sure this is the correct way to solve this issue.

Subscribing to this issue. Having the same problem using Mozilla Firefox, Safari, Opera and Chrome. The bug is not triggered in IE8 as it seems.

Having an autocomplete field on the same edit page as a TinyMCE editor seems like a very common thing, I'm surprised that there are so few of us having this problem. Is is only trigged under certain circumstances?

I see the same thing happening using a normal Taxonomy Tags autocomplete field on the node edit form -- without Autocomplete Widgets installed.

If I use the mouse to click the chosen term from the autocomplete list, everything works fine.

If I use the "return" key, however, the WYSIWYG (TinyMCE) toolbar disappears.

What's worse:

I have a Filefield as a required field in that content type. If there was a file uploaded and "attached" to a node -- (even saved with that node, previously...) -- when the return key on an autocomplete choice wipes out the WYSIWYG toolbar, it also removes that uploaded file as being part of the form submission. The file doesn't disappear when the WYSIWYG field disappears, (it shows no change at that point,) but when I submit the node edit form, the form validation yells that I need to upload a file for that required field, and the previously saved file and description are no longer present.

I'm not completely losing the file or field value since I still haven't yet actually saved the node; if I go back to the node view the file and description are still there...

I hope this helps get us closer to what's going on, though... that it's not solely limited to WYSIWYG.

Regarding the standard Taxonomy Tags autocomplete, I have the same issue as the previous commenter. Using TinyMCE as well.

Marked #967108: wysiwyg editors crash when autocomplete a duplicate. The problem is encountered together with the private message module and that issue currently has a test login to demonstrate the issue.

Bumping this to release blocker because it's really annoying and probably has a simple workaround. You're welcome to correct me if you disagree, Sun.

Tried to look into more generic possibilities. How about this?

Nice, the patch works, why didn't I think of that?

But...

+++ wysiwyg.js	12 Nov 2010 18:01:35 -0000
@@ -67,7 +67,11 @@ Drupal.behaviors.attachWysiwyg = functio
+      if (typeof event.originalEvent.returnValue != event.undefined && event.originalEvent.returnValue == false) {

event.undefined? typeof event.originalEvent.returnValue != 'undefined'?
Just if (event.originalEvent.returnValue === false) { works too since the return value should be false when an event is to be stopped.

Hmm, if I just click a [Taxonomy] autocomplete field and press enter, Core will actually submit the form without attempting to prevent it (at which point Wysiwyg detaches the editor too). That's not our fault though since Core should prevent submits when there's no autocomplete box open too. If it did, this patch would catch that case too.

Powered by Dreditor.

Yup, that should work, too

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Big thanks!

active for D7 version

Why? Please elaborate.

tinymce 3.3.9.3
Wysiwyg "7.x-2.0"
Drupal core field "tag" with autocomplete widget, after pressing ENTER, tinymce (over wysiwyg editors too) disappear.

That is by design. The form will submit when pressing enter in any textfield, and the editor is removed to sync its contents with the original textarea or nothing would be submitted.

This issue is about the editor being removed when the form isn't submitted, as in when selecting an item from an autocomplete-list using the keyboard. That I can't reproduce in D7.

This issue is about the editor being removed when the form isn't submitted, as in when selecting an item from an autocomplete-list using the keyboard.

and I mean this. Not just enter for submit, i about autocomplete-list using from keyboard. But weird that you can't reproduce this...

Oh, now I see. I was testing with Chromium and there event.originalEvent.returnValue gets set, but not so in at least Firefox.

So, I created a path based on #5/#8 since we now have jQuery 1.4.4 in Core.
It works for me in Chromium, Firefox and IE8.

Please test it with the browser you were using as well and I'll commit this right away.

Thanks, now it's work in firefox =)

Thanks for reporting, reviewing and testing, patch is comitted to 7.x.2.x-dev.
Snapshots will be regenerated within 12h and this fix will be part of the next official release.