MoinMoin Logo

Login

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).

• <!> Important issue

• (./) Handled issue

• {i} Issue is not to be handled by moin development

• {X} Bug due to external software. Cannot be solved without important rewriting effort

• (!) Idea

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:

• Open MoinMoinBugs/GuiEditor

• Login
• Select Edit(Gui) text editing option
• Notice how there is no text to edit
• Notice how you can edit using Edit (Text)

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

• If it doesn't happen here, try upgrading to 1.5.7. -- ThomasWaldmann 2007年03月01日 15:57:40

• Note that the space before the word to be deleted has to be a non-bold space. If the space is a bold space, it won't crash.

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:

• the change relating to all_headers already has been done in 1.6
• please explain what exactly your fixes fix
• please explain for each of your changes why they are correct

• maybe consider creating an accound and logging in :)

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.

• We don't use the latest FCKeditor version because there were troubles adapting the plugins needed for moin. If anybody with javascript and python knowledge wants to help with that, feel free - I would love to see the latest fckeditor code, but I am currently low on free time. -- ThomasWaldmann 2006年12月01日 23:00:10

  • It is happening to me to in MoinMoin 1.5.8. I can use Firefox 2.0 fine for the GUI but with IE7 it doesn't work or show after pressing the GUI button. Is there going to be better support for FCKEditor versions in the future or is support fading away as you're not using the latest version anyway? -- Josh2000 2007年11月06日 08:23:14 -AvaterX

    • (./) The browser address pretext, such as www or not, must match your setting in wikiconfig.py - url_prefix. If the user types in the wrong pretext then the GUI doesn't work. Ask server admin or change your Alias settings in htaccess settings to always point to one URL such as http://www.yoursite.com. -- Josh2000 2007年11月06日 08:23:14

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:

•  } else if (navigator.product == "Gecko" &&
   navigator.productSub >= 20030210) {

... 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

• In which JS file did you find this check? Please file a bug with Debian's reportbug and if necessary at FCKeditor, as I guess that it is their code.

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)

• This will be fixed when we integrate next fckeditor release (then fckeditor makes it possible to have multiple css files).

02/02/2006

• Gui editor inserting carets before bgcolor in table cells
  • happens when the page is edited for the first time after the cells have had the bgcolor added
  • this causes much of the following markup to be ignored, not just the bgcolor
  • I see the caret in IE but do not see it in Firefox

02/02/2006

• Frequent "hanging" of gui editor (long running script)
  • Eventually times out and I get a pop-up from the browser saying that a script running on the web page is taking too long to execute, abort yes/no
  • It does not clear up until the browser is closed and re-opened
  • Happens in IE and Firefox both

  • JenniferVanderputten

01/02/2006

• <!> <!> <!> Gui editor line break problems in both IE and Firefox

  • For Firefox, it is inserting line breaks incorrectly and breaking tables
    • The line break is not inserted where you placed it, but rather after the next "word"
    • The newline breaks the table syntax, thus the page displays broken markup instead of the table
  • IE does not have the Firefox problem
    • It is actually ignoring the UseBROnCarriageReturn setting

    • It does not place any <BR> or line break at all, so you must use the BR macro; less technical Gui users may find this a barrier to use (bear with me, I'm trying to advocate Moin as an intranet solution to a wide corporate audience)

  • I apologize if this is already listed -- it sounded familiar but not exactly the same as a previously listed issue
  • My testing was done with Moin 1.5.1, IE 6.0, Firefox 1.5, and Python 2.3.3

  • JenniferVanderputten

  • Same here, very confusing for users, IMHO a issue with the table syntax in moinmoin actually... moinmoin markup becomes very unreadable for large tables because you cannot use line wraps in table cells, only BR. Erich at Debian

  • JS: I hook up with Erich and Jennifer! We want to use moinmoin in a small company as documentation platform (with a couple of tables). Using Firefox 2.0, Moinmoin 1.5.6 (Ubuntu Linux 6.06 package) I experience the break problem when editing tables in GUI mode. Even if I delete the contents of a cell, a newline is inserted so that the resulting page is broken...This is a BIG barrier for a non-technical clerk.

01/02/2006

• Workaround/Fix - Another way, probably the correct way, to create links is just to create them like so [#testAnchor]. This survives the Gui Editor. There is still an issue of why the Gui Editor reedits [:MoinMoinBugs/GuiEditor#testAnchor:testAnchor] to ["#testAnchor"]

• Gui Editor strips all the anchor links

  • a link that points to an anchor on the same page: for example [:MoinMoinBugs/GuiEditor#testAnchor:testAnchor] #testAnchor

    • I noticed that someone edited this page with the GUI editor which highlights the issue. The above link which should point to the test anchor is now invalid. It should look like the link before it.

  • When the page is opened in Gui mode all links on the page gets transformed into ["#testAnchor"]

  • Happens with both IE and FF
  • Any questions - flanderb AT gmail DOT com

15/01/2006

• URL-encoding (eg. %20 replaces a space) would be a great feature and very useful for Wikis in a Corporation.

29/12/2005

• if you do some edits on a page where color in a table is used

  ||<rowbgcolor="#ff0000">cell2 ||cell 3 ||
  ||<bgcolor="#00ff00">cell2 ||cell 3 ||

  • the gui changes the style to empty by saving

  ||<rowbgcolor="#ff0000"rowstyle="">cell2 ||cell 3 ||
  ||<bgcolor="#00ff00"style="">cell2 ||cell 3 ||

• in gui you could create wysiwyg two enumerated lists starting by counter 1

   1.
   1.
   1.
   1.

  • is shown there as

   1.
   2.
   1.
   2.

  This is probably what I want for the formatter too. Saving this gives.

   1.
   2.
   3.
   4.

  • By now it is different to wysiwyg. -- ReimarBauer 2005年12月29日 08:15:37

12/12/2005 Cut/Paste table columns

• {i} NV: Try to cut a column from a Table. Works. Then try to paste this column back -- it will be inserted as a horizontal 1-row table, which is definitely not what you would expect. I couldn't find a way to paste the column back properly. IMHO cutting and pasting table columns is the most important feature in a gui mode, because this is something very cumbersome in a text mode editor. I found that there already exists a bug report for this issue, #1255029.

11/11/2005

• Internet Explorer is not showing text properly after GUI edit. My problem page is a big table roughly 12x13, with a few lines of plain text above it. After editing with IE, the text above the table is 'invisible', although it is still there.

31/10/2005

• <!> RLA: Using gui editor, it randomly looses the space character between words. For example, "There once was a man ..." becomes "There oncewas a man..." (NOTE: This is an example, not a reproducible test case). I do not yet have a reproducible test case (it is completely random as best as I can tell), but will continue investigating. Posting here in the event someone has already seen this issue.

  • I'd guess a end of line problem...

  • RLA: Ok... Looks like the issue is with the applet. The space get's lost once I hit the <ENTER> key after typing in a sentence. I will go to the FCKEditor site and see if anything can be found there. Any suggestions anybody has would be appreciated though. Thanks.

  • RLA: The workaround for this (at least untill it is fixed in the editor) is to change the FCKConfig.UseBROnCarriageReturn = false to true. I cannot seem to reproduce it when set that way. BTW, reproducing the issue is not difficult... simply type a relatively large amount of data and hit <ENTER>. Once I set the FCKConfig.UseBROnCarriageReturn property to true in moinfckconfig.js in moin/htdocs/applets, the problem went away. NOTE that there is a warning about changing it to true in a comment above the property: "when true, IE has problems selecting a line of text and tends to select a whole paragraph"

8/9/2005

• TODO: strip BR (or P?) from table cell content as this will break moin's tables. Maybe replace with [[BR]]macro call

• bulleted / numbered lists and cut/copy/paste problems:

  • <!> JJK: Most Cut&Paste problems are due to the fact that when you delete a bulleted or indented line, the bullet or indentation is left behind and sometimes applied to the following lines. This happens as well with Firefox as with I.E. and is a bad behaviour of the FCKEditor!

    • Example : <ul><li><p>AA </p></li></ul><p>BB </p>. If you select the AA line and delete it, you will get <ul><li>BB </li></ul>.

  • <!> Frequently, bullets are left behind. Happens when you try to delete or move up the second line in a list of at least 3. Remove the "format" markup and try to select and delete the "bb" line in both cases.

 1. aa 1. bb * cc * dd

or

•  * aa * bb == cc ==

• TW: {i} I think I also have seen such effects. They are likely browser edit control bugs, mostly missing redraws. I don't think we can fix them. This was confirmed by another (non-moin) FCKeditor user, he also has seen that.

• JJK: Cut&pasting of indented bullets goes wrong most of time and you have to make manuel cleanup afterwards. Please ask FredCK about it.

• TW: filed a fckeditor bug for this, see: https://sourceforge.net/tracker/index.php?func=detail&aid=1274834&group_id=75348&atid=543653

• Little anomaly (low priority): if you insert two drawings or a drawing and a picture in a page, you will get an unnecessary horizontal scrollbar in your GUI editor window (I.E. only)

  • {i} TW/FCK: This is an IE bug. In FCKeditor there is the "IEForceVScroll" configuration option to makes it always show the vertical scrollbar. In this way the horizontal one doesn't appear when not needed.

• JJK: When you add a smiley behind a text, the whole text becomes selected (Firefox only)

  • {i} TW: confirmed. FCK: it is a browser bug.

• Bulleted, indented lines: when you click again on the "bullet" button, it doesn't remove the bullet but behaves the same as "decrease ident"
  • In Firefox, it removes the bullet, it doesn't remove all indentation though. Maybe this is another IE bug?

  • {i} Filed a bug here: https://sourceforge.net/tracker/index.php?func=detail&aid=1274848&group_id=75348&atid=543653

• Could you show/highlight the actual format (Heading) in the drop list when you select a text

  • {i} TW/FCK: IE limitation (bad design), works with Firefox.

• Merge "Insert/Edit Link" and "Remove Link" ("Remove Link" link in the "Edit Link" popup)

  • {i} Added a feature request: https://sourceforge.net/tracker/index.php?func=detail&aid=1274853&group_id=75348&atid=543656

• Rename "Insert Smiley" to "Insert Icon" (2 times)

  • Added a feature request: https://sourceforge.net/tracker/index.php?func=detail&aid=1274859&group_id=75348&atid=543656

20/7/2005

• Lines following a comment line are merged. Create 3 lines separated by blank lines (##aa,bb,cc). Each time you make a preview, a blank line following the comment line is removed. You finish with ##aa,bbcc. This was also in the previous version.
  • TW: confirmed with Firefox. Kind of a black hole.

Older

• Can you remove the "grey background" attribute when you start a new line with a return after a comment line (disappears only after a preview)?
• Missing "goto anchor" feature. You might want to add this option in the "Insert/Edit Link" dialog box (low priority)
• Text is cut: when applying "Superscript" "Subscript* or "Big", part of the characters are cut away.

  • JJK: This happens with IE and you are at the last line of the page. After pushing <CR>, text is correctly displayed.

  • TW: OK, so this is a IE font rendering problem (we can't fix IE). BTW, some word processors sometimes also behave a bit strange in that respect.
  • TODO: check if this is influenced by line height in CSS or total editor height.
  • JJK: when a long line wraps, superscipted "l, t" etc can overlap subscripted "q, p" etc.

• (./) TW: inserting an interwiki link works on current IE6 (and Mozilla, FF, etc.)

  • TW: it doesn't work on IE5.5 due to a bug in IE5.5 we can't work around (it simply drops the class attribute we set)
• TW: after many hours of unpleasant IE JS debugging we disabled the selection plugin (that cared for disabling controls that must not be used in a specific context), so you currently have to be careful to not generate content that can't be done with wiki markup. This currently "avoids" the following problems:
  • selection #291, oNode kann wohl Null werden und dann knallt's
  • selection #86, invalid argument (oNode == "")
  • With IE: Javascript Error in line87 char3 when editing normal text (e.g. the first char of "Tried", see first item above).
  • cursor autorepeat doesn't work in IE. In Firefox it is OK.
  • Try to make that FCKConfig.UseBR teletype style with IE. Most icons are disabled when selecting text.
  • Buttons are very frequently inactive. This has to be solved in some way!

• Tried to change FCKConfig.UseBROnCarriageReturnto true, but that makes troubles. IE tends to select a whole paragraph instead of a single line then. Adding lines to a PRE section would work, though.

• <!> Line breaks :"CR" => <p> with IE and <br> with Firefox (which are removed). Could you for both browsers support simple line breaks by generating a <br> tag which would be replaced by a "BR" macro?

  • The problem is that not "we" are generating those HTML tags, but a built-in control in the browser.

  • Just replacing all <br> tags by
    would make a big mess, because some browsers insert this tag at strange places (even when you never hit the ENTER key there).

  • There should be a config option to make to IE produce <BR>s. This should make the <PRE> fix unnessesary.

• List the personal pages ordered in 3 groups (P:personal, R:readonly, W:write)

  • either create 3 subpages UserName/P,... and add the pages one level deeper

  • or add a prefix (P_, R_, W_) when creating personal pages

Not bugs, rather notes

22.10.2005 - How to fallback to text edtior

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.

• TW: When setting up some sort of "production wiki", please read the Apache 2 stuff on AutoUpdatingStuff before. Will help for all browser caching related issues. /!\ Please check the page again, the expiry for text/html was far too long and caused problems especially when after saving pages with IE.

• (./) Avoid a multiple refresh after clearing a message, making the page jumping up and down several times

  • JJK: This problem has disappeared after removing the picture in before the interwiki links
  • This is due to IE bugs / missing featurers being fixed by IE7 hack. I asked Dean Edwards (IE7 author) if he can improve this. (TW)

  • See also here for a workaround.

To be done by FCK

• Tables: drop list shown on right click is too short. Last line (Table properties) is cut.

  • {i} TW: works with Firefox, but the menu is too large to fit on small screens in quite some cases.

• Group following seldomly used functions under one button : Insert Smiley => Insert Icon, Insert Special Character, Universal Keyboard.

---

CategoryMoinMoinBug