Item2368: NatEdit doesn't always hide its toolbar for TinyMCE

Resulting in the interesting result (attached).

After placing some console.log() around the place, it seems we don't always have a valid #topic_ifr around line 55 of edit.uncompressed.js, despite the 100ms timeout.

Options:

1. Fire NatEdit's WYSIWYG handling code on window.load instead of document ready/timeout (see attached). TinyMCE loads its components (plugins, images, .html files, etc) asynchronously and so it's really difficult to assume anything about TinyMCE's state of readiness, unless...
2. Refactor NatEditPlugin's TMCE interactions as a TinyMCE plugin so it can reliably hook into TinyMCE.activeEditor.onPostRender
3. Or implement a Foswiki API to reliably register callbacks with or without TMCE being ready; a special foswiki plugin shipped with TinyMCEPlugin could then provide the means to reliably dispatch.

• natedittoolbar_hide_fail.png:
  

• NatEditPlugin.diff: use window load event to ensure TMCE is ready

-- PaulHarvey - 17 Nov 2009

Option (2) sounds good. How difficult is it and how does it affect NatEdit running without TinyMCE?

-- MichaelDaum - 17 Nov 2009

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.

-- PaulHarvey - 17 Nov 2009

Added your patch.

-- MichaelDaum - 17 Nov 2009

New defect:

• wrong_initial_size.png:
  

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.

-- PaulHarvey - 20 Nov 2009

Re-opened and set WaitingFor Michael so he can make a new release.

I suppose I shouldn't close something until the fix has been released for the plugin.

-- PaulHarvey - 21 Dec 2009

Seems fixed in the latest release.

-- MichaelDaum - 10 Jan 2012