This page was nice for summarizing some issues in the past.

(!) Please report bug reports for the gui editor on MoinMoinBugs.

Someone regulary using the guieditor please clean up this page.

Description

This is a collection of issues related to the graphical (GUI) editor. Either bugs in the browser, in FCKeditor or in MoinMoin code.

Issues

Please create a new header for every day and enter new or move modified entries and answers under this header. To easily identify who gave which answer, prefix any response with your initials (i.e. JJK, FF, TW).

JJK: Tested (if not signaled otherwise) with Windows XP & I.E. 6.0 Sp2.

2009-07-21

When picture is paste from clipboard (CTRL+V) with firefox 3.5.1 I get following result:

file:///Z:/TEMP/moz-screenshot-7.png

I would expect attachment created and picture displayed. Is anythink I should add in some config file ?

2009-06-10

The editor seems to lose the bold off whole lines.

This edit is an experimental example of this - unfortunately I can't reproduce the effect in this wiki. Anyone had a similar experience?

(!) Maybe check the MoinMoin version you use (see your SystemInfo page). Since moin 1.8, we have an updated gui editor. -- ThomasWaldmann 2009-06-10 16:05:38

2008-10-14

I went to this page to report that the "Insert Smiley" is not working only for the first icon/emotion from left to right in the first line.I tested this using both Firefox 3 and also IE 6.0.2.

 If you try insert that emotion, it not insert, if you click on it, nothing does. But all others icons/emotions works, when you clik on they, they are inserted on wiki. Try it yourself and see if you get the same results

Fixed by: http://hg.moinmo.in/moin/1.8/rev/d53527e1264e

2007-03-24

I went to this page to report that the Edit(GUI) is not working on our local install of the 1.7 code. Then when I got to this page, I found the same problem. I tested this using both FireFox 2.0.0.12 and also IE 7.0.5730.13IC.

Try it yourself and see if you get the same results, using these steps:

Additional information about our install: We're using CherryPy and moin.cherry.py script (if that helps)

2007-03-01

Hi. Doing the following causes Internet Explorer (6 & 7) to freeze. Does NOT in Firefox 2.0.0.2 on Win XP SP2. Eventually (after a minute or two) a Javascript error appears stating that "a script is taking running too slowly..." The user must choose Yes to stop running the script or remains hung.

The following code has bold immediately followed by plain text. In GUI mode, put the cursor on the 'S' in Someone. Press the Delete key 3 times.

Who: Someone or Other

Moin version is 1.5.6.

I see that it doesn't happen on this wiki though. Any ideas how to help debug this?

HaroldShip

2007-02-01

Fix for moinFCKplugins on Firefox 2.0 on the development (1.6) code base: FCKeditor-2.2-fixes.diff

Thanks for the patch:

2006-11-29

Gui editor toolbar not starting in Firefox 2.0 on Win XP. When I click on Edit(GUI) in a MoinMoin wiki, the toolbar does not show up. However, if I go to the [ http://www.fckeditor.net/demo fck editor demo ] , it works. Here are the errors I get going to the edit(gui) page: 

this.DOMDocument has no properties
applets/FCKeditor/editor/js/fckeditorcode_gecko_2.js
Line: 22

and... 

pattern has no properties
applets/moinFCKplugins/selection/fckplugin.js
Line: 329

Note: I had to copy the text of the error from the error console, so there might be some mis-spellings, but the line numbers are definitely correct.

2006-08-04

h1 h2 h3...etc header definition elements are not matched up properly in GUI Editor.

When you select Heading 1 in the GUI Editor, it correctly applies the h1 definition to the selected text, but within the editor window, it displays using the h2 definition. The preview correctly shows the h1 definition.

This problem also shifts h2 to h3, etc. All the hx definitions show up as h(x+1)

This is not obvious in the default theme, but using the rightsidebarsmaller theme, it is obvious because h1 doesn't have a blue rule and h2 does. The preview doesn't match the edit window. -eschanberger at yahoo

2006-05-12

GUI editor not started on Debian sid. The following check fails here:

... as productSub is Debian-1.5.dfsg+1.5.0.2-3. Now that version number might be wrong and evil, though... -- TheAnarcat 2006-05-12 22:32:16

2006-05-05

When I open inside a modal or modeless window some thing goes wrong for example I cannot edit cell properties of a table, i cannot set hyperlink to my texts --Jaynak

2006-04-20

The following GUI editor bug occurs with both IE and FF browsers. Edit a hyperlink (change an existing hyperlink to something different), then click preview or save. The change is gone, and the hyperlink is back to what it was before. This occurs with both URL and wiki page hyperlinks. The only workaround I can find is to remove the hyperlink, then create a new one with the desired modification. Let me know if I should file a bug for this (I have not looked to see if it is a bug already filed). --JenniferVanderputten

2006-02-20

ND: Looks like Fckeditor only uses common.css to determine it's own style. I think it should source screen.css as well! (important for dark themes, where you don't want to put your screen colors to common.css because of printing)

02/02/2006

02/02/2006

01/02/2006

01/02/2006

15/01/2006

29/12/2005

12/12/2005 Cut/Paste table columns

11/11/2005

31/10/2005

8/9/2005

 1. aa    1. bb    * cc    * dd

or

20/7/2005

Older

Not bugs, rather notes

22.10.2005 - How to fallback to text edtior

url param

JS

user pref

result

edit

on

gui

gui

edit

off

gui

text

edit

*

text

text

edit&editor=text

*

*

text

edit&editor=gui

on

*

gui

edit&editor=gui

off

*

text

url param:: as specified by user / theme author (JS might change it internally) JS::on/off whether user has javascript enabled or not (we also require some specific sw version as JS alone is not enough for gui editor) result:: what the user will get as editor

The problem is how to handle the case when the link say editor=gui, but javascript is not enabled, or the browser is not compatible. The only solution I can think of is redirect to currentpage?action=edit&editor=text in this case.

This can be implemented by sending the user a tiny html that redirect to the text editor, with tiny javascript code that will override the redirect href with the real gui editor href.

snif.html: 

<html>
<head>
<script type="text/javascript" src="snif.js"></script>
<script type="text/javascript">
if (canUseGUIEditor()) window.location.href = 'gui.html';
</script>
<META HTTP-EQUIV=Refresh CONTENT="0; URL=text.html">
</head>
</html>

snif.js: 

function canUseGUIEditor() {
    return true;
}

Test here: http://nirs.dyndns.org/~nir/snif.html

This will create a two requests for each request to edit a page with the gui editor, but will make sure we have a correct fallback.

Or we can simply send the text editor, with a javascript redirect to the gui editor. If the javascript will not run, you get the text editor. If it run, you get the gui editor. This will create more load on the server, as you need to send the text editor content and then the gui editor content.

To be done by FCK

CategoryMoinMoinBug

MoinMoin: MoinMoinBugs/GuiEditor (last edited 2012-10-05 10:12:08 by ThomasWaldmann)