Integration: Trigger javascript on WYSIWYG attach?

I know you directed question to sun, but I hope you don't mind me answering it.

Wysiwyg module does not have a callback or similar method to notify 'outside' code that an editor has been fully attached, partially because Wysiwyg module itself does not have this information. The editors load asynchronously and Wysiwyg module doesn't listen to their 'I'm loaded' events (Might change in 3.x). It does however register plugins, which do get these events, given that the current editor supports plugins and the implementation layer does too. But none of the solutions I can currently think of are pretty or practical...

You could implement native plugins for each editor, implement a wysiwyg module hook to tell the editors about these plugins and get the element(s) you need to register a dropzone.
Pros: You can act on any event the editor triggers. It's relatively easy to figure out which element to set as your dropzone and use the editor API to get it.
Cons: Not all editors support native plugins, and not all of our editor implementations are yet able to register them in the editor. Lots of APIs to learn and plugins to write. Different code for each editor added to the module.

You could implement a 'Drupal plugin' (editor independant plugin), which will be called each time content is retrieved from or sent to the editor.
Pros: One piece of plugin code to write, only against the Wysiwyg API. In theory at least...
Cons: Even fewer editor implementions support Drupal plugins yet. The Wysiwyg API does not react to/relay the exact events you need. You only know that content is grabbed from or sent to the editor, which can happen at any time. No direct access to the editor API via Wysiwyg module. You can still figure out the name of the editor, but after that you're on your own and it's back to customized code for each editor.

You could use your own code to check for the existence of each editor's API and manually register some event handlers/callbacks for each available API and work from there.
Pros: You know when each editor instance is done loading. You'll also know when an editor is unloaded.
Cons: Not all editors have an API which makes this possible. Once again, lots of APIs to learn and much code to write. The global API might not even exist before an editor instance does (FCKeditor).

It would help immensely if you could tell more about the info you need from the editor and how these dropzones work. Then we might be able to work out a solution and get the 'right' features into the 3.x API.

I just saw you pinged me on IRC, was out at the time...

A hook at the end of Drupal.wysiwygAttach probably won't help much if you need to get reference to editor controlled elements, like its iframe. The editors are still not loaded when that function exits so the state of their markup can be anything. Most of them have gotten as far as creating the iframe for the editing area, but the contents in the iframe load asynchronously. Scripts in the iframe won't run until all other script execution on the main page is over (or at least temporarily halted if there are unexecuted setTimeouts, setIntervals etc) and those scripts usually change things in the main document as well. What the top element in the editor's 'domain' looks like and where it was placed is entirely up to the editor. Wysiwyg module figures out which editor instance to talk to based on the original textarea id and tries to avoid poking around into whatever markup the editor has created.
The hook would only tell you that Wysiwyg module itself is done, but any code running in the hook will further delay the editor loading so it's not safe to access any API to get more info about an editor at that time. We also do not know if the editor's markup in the main document is final.

It's correct that the "instance id" set to Drupal.wysiwyg.activeId is the id of a replaced textarea. It changes as soon as an editor is attached or gets focus (in practice, is clicked or tabbed to), but I can't guarantee that it has a chance to update before the drag/drop event fires so it might not actually point to the field you're interested in.

If you can set the dropzone to be the field's wrapper element ('#[field-id]-wrapper') you could use your regular Drupal behavior to make the entire area around a field a dropzone. That element is never changed by Wysiwyg module or any editor as all the 'action' happens inside it. Events will only have to be attached once, but events fired inside the editing area can not bubble up high enough if there is an iframe barrier. We'd need the editor to support the relevant event and register a listener through it. (That's why I had the native plugin thing in mind.) But I think I might be able to get around that, need to play around with your module a bit to be sure though.

Once some relevant element is designated a dropzone and a successful drop is detected it should not be so hard to figure out what to do. In the actual drop handling code, you check with Drupal.wysiwyg.instances[field_id] to see if Wysiwyg module controls a field. If an entry in the instances array exists, you can use Drupal.wysiwyg.instances[field_id].insert('[Reference to uploaded file]') insert the upload reference at the cursor position. If no instance for that field exists, Wysiwyg module does not control it and you can fall back to manually inserting the upload reference into the regular textarea (note that some other WYSYWIYG module might still have replaced the element with an editor).

I'm in Sweden so I have some problems getting in touch with other devs too sometimes. Especially sun, which is a bit strange since he's from the same timezone as me hehe.

I'd be happy to take a look at your code. You can use my contact form to send a link if the code is online somewhere, otherwise I'll reply ASAP so you can send it as an email attachment.

Note that the code to attach dropzones would have to run each time an editor is attached, as editors are completely destroyed when detached.

There are a couple of issues (and patches) about adding the insert method to more editors. And now that you mention it, I really should get around to commit those soon and add it for more editors... A couple of other modules are also waiting for those methods

I was going to write something more but I forgot what. Probably just as good since I tend to write too much. ;)

Similar issue.
#859232: activate button on load - how to execute TinyMCE command on load
I'm trying to execute some javascript code on WYSIWYG load.
I don't know where to find the solution.

setTimeout is not the solution. For sure there should be something 'onload'.

I've problem with setTimeout() solution, because when set to 5sec, after that time I lose focus of my current element and it's breaks what I type.
See: #861654: Load Spell Checker button on page load

Some workaround as well:
http://drupal.org/node/135755#comment-2662178
Almost works after TinyMCE is rendered, but the content is empty.

Trigger on add:

tinyMCE.onAddEditor.add(function(mgr,ed) {
  console.debug('onAddEditor: ' + ed.id);
});

And this if you need some triggers when content is loaded:

/**
 * Attach this editor to a target element.
 *
 * See Drupal.wysiwyg.editor.attach.none() for a full desciption of this hook.
 */
Drupal.wysiwyg.editor.attach.tinymce = function(context, params, settings) {
  // Configure editor settings for this input format.
  var ed = new tinymce.Editor(params.field, settings);
  // Reset active instance id on any event.
  ed.onEvent.add(function(ed, e) {
    Drupal.wysiwyg.activeId = ed.id;
  });
  // Make toolbar buttons wrappable (required for IE).
  ed.onPostRender.add(function (ed) {
    var $toolbar = $('<div class="wysiwygToolbar"></div>');
    $('#' + ed.editorContainer + ' table.mceToolbar > tbody > tr > td').each(function () {
      $('<div></div>').addClass(this.className).append($(this).children()).appendTo($toolbar);
    });
    $('#' + ed.editorContainer + ' table.mceLayout td.mceToolbar').append($toolbar);
    $('#' + ed.editorContainer + ' table.mceToolbar').remove();
  });
  ed.onPostRender.add(function(ed, cm) {
    console.debug('onPostRender: ' + ed.id);
  });
  ed.onLoadContent.add(function(ed, o) {
    console.debug('onLoadContent: ' + ed.id);
  });
  // Attach editor.
  ed.render();
};

This one is not a proper way, but it does work.

Probably we should have some feature which allow to define additional custom functions onPostRender and onLoadContent without overriding Drupal.wysiwyg.editor.attach.tinymce.

I think above modification of Drupal.wysiwyg.editor.init.tinymce (onPostRender and onLoadContent events) could be extended that allow to execute some JS code from other modules (module_invoke_all, but in javascript).

Actually, jQuery allows us to create custom events and fire them at will, which is how I indend for this to work in Wysiwyg 3.x.

So how to convert overridden version of Drupal.wysiwyg.editor.attach.tinymce in #13 to jQuery way which will run some code on onPostRender and onLoadContent events?

I can't promise this is the exact way it'll work in the end, as we have to compare capabilities and available editor events across all supported editors, and I'm writing this on my phone at work without references available, but it's a start.

In the event handlers in #13 (where stuff is now printed to the console), we'll call jQuery's .trigger method and pass it an event name and some useful parameters, like the editor instance, other modules can then react on these (global or perhaps per field) events by passing one of the event names and a callback function reference to jQuery's bind method.

To make this useful, all Wysiwyg events would have to be triggered from within all editor implementations in reaction to events generated by the implemented editor. In short; Wysiwyg will become a cross-editor event relay/proxy joining editor libraries and Drupal code.

Of course, not all editors support all the events triggered by the big editors like TinyMCE, FCKeditor, CKEditor or YUI Editor, so we'll have to be a bit clever in implementing this. Perhaps even "patch" editors at runtime, which we already have to do in some cases to be able to communicate with them at all.

Drupal 6 is no longer officially supported. If you think this issue is still relevant for 8.x, feel free to re-open.