We could take all of the WYSIWYG code out of NatEdit and put it into the new TMCE plugin. So it doesn't affect NatEdit at all until TinyMCE loads the plugin.

It's not very difficult, however, I am now juggling a couple of other (unreleased) TMCE plugins that all seem to be exposing some weaknesses in our Javascript API when it comes to interacting with TMCE. And I had a go at reworking ChapterEditPlugin to be Wysiwyg friendly today; I ended up with a working but brittle (cancelling event propagation) hack, which could be much better if we could adjust slightly the way we all mess with callbacks.

Have you ever observed this problem (NatEdit toolbar fails to hide) before? I have never received any complaints from users, but testing our wiki over a low-bandwidth (64kbps)/high latency (800ms) network simulation seemed to reproduce the problem about one in four or five times I attempted to launch the editor.

Interestingly, I could not reproduce this behaviour easily unless I used a widescreen monitor - almost impossible to reproduce unless browser window's viewport area is double the minimum NatEdit width (screenshot shows roughly the minimum window width required to reproduce the bug).

Using window.load event means that we can be sure TinyMCE is ready, but also it means TinyMCE has sometimes already done the switchToWYSIWYG() before NatEdit gets a chance to patch it.

So the resize.natedit event is never triggered, and the user gets the interesting arrangement shown above.

Really, we need a better way of hooking in to TMCE events. I'm thinking about it.