You are here: Foswiki>Tasks Web>Item2368 (10 Jan 2012, MichaelDaum)Edit Attach

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

Priority: Urgent
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: NatEditPlugin
Branches: trunk
Reported By: PaulHarvey
Waiting For:
Last Change By: MichaelDaum
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.

  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:
    natedittoolbar hide fail.png

-- 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:
    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
I Attachment Action Size Date Who Comment
NatEditPlugin.diffdiff NatEditPlugin.diff manage 1 K 17 Nov 2009 - 04:43 PaulHarvey use window load event to ensure TMCE is ready
natedittoolbar_hide_fail.pngpng natedittoolbar_hide_fail.png manage 24 K 17 Nov 2009 - 03:41 PaulHarvey  
wrong_initial_size.pngpng wrong_initial_size.png manage 54 K 20 Nov 2009 - 13:39 PaulHarvey  
Topic revision: r15 - 10 Jan 2012, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy