Drupal core has a formUpdated behavior, however it doesn't generally work with WYSIWYG editors because it relies on keyup events on the underlying field.

The behavior is:

/**
 * Sends a 'formUpdated' event each time a form element is modified.
 */
Drupal.behaviors.formUpdated = {
  attach: function (context) {
    // These events are namespaced so that we can remove them later.
    var events = 'change.formUpdated click.formUpdated blur.formUpdated keyup.formUpdated';
    $(context)
      // Since context could be an input element itself, it's added back to
      // the jQuery object and filtered again.
      .find(':input').andSelf().filter(':input')
      // To prevent duplicate events, the handlers are first removed and then
      // (re-)added.
      .unbind(events).bind(events, function () {
        $(this).trigger('formUpdated');
      });
  }
};

The CKEditor module implemented a workaround for this in #1895278: WYSIWYG editor should allow Drupal to trigger 'formUpdated' event.

Since this module deals with a bunch of different editors and I'm not very familiar with the module's code I'm not sure if the same solution maps exactly to WYSIWYG.

Comments

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

The same solution could map the same for the CKEditor integration code, but most editors provide few or none of those events.
We could probably trigger at least one of the change/blur events when editors have been detached (at which point they should have synced contents back to the original textarea), but I don't see much reason behind relaying repeated in-editor events like keyup back to the original textarea since it may not have changed at all yet. I don't know if that could cause bugs in say modules that look for and expect at least one character to have changed in the textarea on those events and not actually finding a change. I suppose expecting that could be considered a bug as well though...