Firefox, IE7 and Opera each seem to have their own way of dealing with the way NatEditContrib
manages its toolbars when a wysiwyg editor is shown:
- Firefox: hides everything except save/preview buttons based on element names (hide_in_wysiwyg)
- IE7: hides everything, no buttons are shown. (i.e. no way to save your text)
- Opera: shows everything, no buttons are hidden
Editing the template
and removing class
fixes most of the problems. Firefox behaviour remains the same, and IE7 shows the entire toolbar.
- 21 Dec 2007
In my setup (TWiki 4.1.2 with TWiki:Plugins/NatEditContrib
) the situation is the following (when using the WYSIWYG editor):
- FF2: Only save/preview/cancel buttons are shown (as intended).
- IE6: Initially, all buttons were shown. I found out that
getElementsByName that is used in
edit.js to hide the buttons isn't recognised by IE6 for all elements (for once, IE is actually closer to the W3C standard as
getElementsByName can only be used for
form elements in XHTML). My work-around was to use
getElementsById which is a bit of a hassle since you have to use different IDs for all the different buttons.
Additionally, I've got the following two problems:
- When saving in IE6 I get a popup telling me that I'm leaving the page and that
all changes you made will be lost. If I then click
OK, the topic will be saved fine but it's rather confusing. This is TinyMCE trying to take over control. So far, I havent' found a fix.
- When using NatEdit and clicking the checkpoint button, the topic is saved but then reopened in WYSIWYG. I guess this is not intended.
Should I open new bug reports for the last two issues?
In general, I guess it would be best to completely separate the UI for the two editors, i.e. continue using the save/checkpoint/cancel buttons below the text area for WYSIWYG and only using NatEdit's buttons for NatEdit.
- 22 Feb 2008
Stale: Setting unmaintained extension to "no action required".