Extend JavaScript API to react on events

Good proposal.

Point 2 is already planned for Wysiwyg 3.x and is fairly straight forward. Point 1 might be a bit tricky if the editor itself has no native hook/event for that, but should be possible.

Is there any event feature for real-time spell checker?
Or any workaround? Similar to autosave module?

This would be a great improvement of the module. Willing to help implementing this.

Better late than never.

This was indeed tricky to implement across all supported editors and version, more so than I expected.
The implementation is based on the flow from Drupal 8's Editor/CKEditor modules, with a few adaptations and additions of course.

Each field will now trigger a custom drupal-wysiwyg-changed event which gets passed the relevant Wysiwyg instance in as a second argument next to the event object. Note that any summary fields attached to textareas are treated as separate editor/Wysiwyg instances.

It also includes a confirmation dialog when switching between formats, for the same reasons D8 warns you when switching formats. I've encountered users which have been confused by this before so might as well include it as it also works as a way to verify change detection is working.

Testing all this with every supported editor version has been a pain so I automated most of it using Intern outside Wysiwyg itself. (https://theintern.io/, not an actual intern.)

As several of the editors do not have native "change events" there is a ElementWatcher helper which can monitor both textareasand contentEditable-enabled elements.

(https://theintern.io/, not an actual intern.)

😆

What's next here? You've already done the testing, you're a module maintainer … so do we just commit this and go ahead?

Yeah, we had a policy to not commit before any external review, but with the low activity here now I'm going to sidestep that.

Accidentally pushed the wrong patches first and force-pushed patched with the diffs to the correct ones, so the bot messages above aren't [currently] pointing to the right hashes.
They contained an extra condition checking if the editor contents were also empty if the field was empty - meant to cover an edge case where you've entered contents into a previously empty field and then switched formats. Since several editors leave behind empty tags even when there is no visual content this check caused it to show up almost every time.

This commit breaks editing full HTML fields that have ckeditor disabled for us. Tracked this down with git bisect. Our scenario is a news article where we have multiple wysiwyg fields. Steps to reproduce:

* Switch text field to full HTML (ckeditor 4.11.4 disabled on that field)
* Modify text area & save node
* Changes to the field are not saved and the old field content is shown

@klausi Thank you, good catch! Sorry I missed your message, normally don't look at closed issues.

I've pushed a commit which fixes that and moves the relevant part that was in none.js into wysiwyg.module as I found the change tracking resetting itself on editor attach somewhat convenient, but mostly confusing. Made the code flow a bit easier too and makes that attribute flag a bit more useful for other scripts too (read-only) and lines up better with how D8 core does it.

I'm prepping for another release, just need to make sure I've verified the latest releases of the supported editors and then this will be out.

EDIT: Not sure why the bot hasn't picked up the commits, but maybe it doesn't look at closed issues either.

D7: a1485d5
D6: a895095