We've fixed this by changing the html macro so that it doesn't render the html in the Rich Text Editor ((see above). You can upgrade the html plugin to version 1.9 to get this fix immediately.

Dear Rian,

This will most likely be fixed as part of the new editor work for 4.0 which is currently under way.
Please refer to http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+FAQ for more details.

Please accept my apologies for the inconvenience.

Kind Regards,
Partha Kamal

Worse still: when I open up a page on which I have used the

macro, this effect messes up the code before I even have a chance to switch to the Wiki Markup Editor. I can't switch to "start in wiki markup editor" without messing up everyone else in the company. So I don't dare edit any of these pages! I have already lost some Javascript that I spent a long time writing and debugging. Anybody at Atlassian listening???

I'm having the same problem with the html macro. My main problem apart from the fact that whenever I write a <br> tag, every time I re-edit the code I get a new pair of <br></br> tags is that I get that nonsense code every time I write a div between the html macro tags:

<P class="atl_conf_pad"> </P>
<DIV class="wysiwyg-macro" macrohasbody="true" macroname="add-box" wikihasprecedingnewline="true" wikihastrailingnewline="true">
<DIV class="wysiwyg-macro-tag wysiwyg-macro-starttag">

Also, I am not able to write a script tag inside this macro, as the next time I try to edit the page it would disappear and I'd get just a pair of <p></p> tags. Of course the solution creating the new user macros work, but this is not a huge or very complicated problem to solve by Atlassian -or at least there should be some note under this macro regarding this problem, so when a new user tries to do something, he/she doesn't lose the work done.

I'm hoping for next version (already in 3.2.*) someone does something, either updating the documentation or fixing this problem that has been around for more than enough time.

This is pretty annoying considering the HTML macro should be a non-rendering macro. The fact that this issue was originally reported in 2007 is not encouraging... I really don't think creating our own 'myhtml' macro should be an acceptable outcome here considering that "fix" would have to be communicated to every single user of the system. I'm running 3.1.

This is still happening in 3.1.2

Linking to umbrella issue

We recently upgraded from 2.9.2 to 3.0.2 and this issue reared its ugly head again.

Under 2.9.2, some enterprising users decided to design some relatively complex tables within

macros, but then discovered that editing the tables in the Rich Text Editor actually worked.

Unfortunately in 3.0.2, the RTE is now adding <B></BR> pairs throughout the page whenever it is edited.

Doubtless this is a relates to the problem of the RTE parsing the HTML when it shouldn't. The above workaround of creating a non-rendering User Macro does the trick, but my users are not going to be happy about this perceived loss of a feature and having to edit HTML by hand.

I guess I'll have to see whether we can format their page with regular Confluence tables macros.

In my testing, you can work around this problem by adding a user macro called something like "myhtml", with the options displayed here:

The content of the user macro can survive a round trip to and from the Rich Text editor a lot better (although notably the exclamation point gets escaped in my testing).

Looks like this was actually a combination problem that I wasn't aware of. We had Bob Swift's HTML plugin installed, and the combination of having that enabled and the internal Confluence macro apparently will cause the behavior above. I guess it's actually possible to have two incompatible macros on the same macro tag, makes troubleshooting interesting!

Hi John,

If you put any amount of data between

Unknown macro: {html}

tags in the Wiki Markup Editor and then switch to the Rich Text Editor, that data is gone and unrecoverable.

In general case this problem does not happen, although the formatting may get corrupted the data will not be lost. Can you please provide a specific example when the problem you describe happens?

Anatoli.

"I'm not too surprised by that behaviour. We upgraded TinyMCE to version 3.1 (from 2.x) in Confluence 2.10, and it's handling of scripts must have changed. Realistically this isn't something we will be looking into with high priority so I suggest working around it."

I'm very very surprised to hear this. This is a content corruption level of a bug, and it's considered not a priority? Understand the level of the problem here:

If you put any amount of data between

tags in the Wiki Markup Editor and then switch to the Rich Text Editor, that data is gone and unrecoverable. When you switch back to the Wiki Markup view, everything is simply gone. This is something we have just run into, and I'm amazed that this is a common/known bug with no fix.

The RTE does not display the HTML at all – it displays nothing, as soon as you switch from Wiki Markup to Rich Text, it is simply removed. There's no rollbacks/etc to recover the lost work.

What strikes me as odd about the HTML macro is that it renders the html in the RTE at all. This seems to me (and I must admit I don't prefer the RTE) to be the wrong thing to do. This is always going to cause the RTE to mess with it, and it's going to limit the extent to which you can edit the macro body in that editor.

The macro should escape the html in the RTE so that you can edit completely. That is, if your wiki markup is (without the noformats):

{html}
<b>blah</b>
{html}

Then you should see:

{html}
<b>blah</b>
{html}

Rather than
{html}
blah
{html}

I think that would be the right behaviour, and it would certainly be less error prone.

Hi Ben,

Unfortunately rolling back the version of TinyMCE is not really an option, given the number of changes that we had to make to support it in Confluence 2.10.

Regards,
Andrew Lynch

Voted. Please fix! is there an earlier version of the MCE we can roll back to?

Hi Ed,

Thanks for reporting this.

I'm not too surprised by that behaviour. We upgraded TinyMCE to version 3.1 (from 2.x) in Confluence 2.10, and it's handling of scripts must have changed. Realistically this isn't something we will be looking into with high priority so I suggest working around it.

I suggest you write user macros to create the dynamic data you want instead of using javascript. Or write user macros that create and call the javascript functions you required.

Cheers,
Don

Anatoli,

I'm seeing the same issue (with embedded JavaScript) that Darryl described. This is with Confluence 2.10.1.

I have boiled down our more complicated page to a small page that shows the same issues. Here's the Wiki markup:

–

Rich Text Editor Eats JavaScript

If you edit this page using the Rich Text editor, the JavaScript calls appearing in the cells disappear (but not any straight HTML in the table). This used to work as one would expect in our old version of Confluence (that is, the JavaScript did not disappear). For a more complicated example of this (but with exactly the same problem), see [conflab:Test Copy of QA Portal].

–

This page displays fine as long as you edit it with Wiki markup editor. If you select Rich Text, the JavaScript-generated portions disappear in the editor, and if you save it, you get <#comment> where there should be other text. The text and the JavaScript function definitions are still fine, but the resulting Wiki markup for the table is now:

–

1. scripts are still intact, but the table is corrupted:

<TABLE border="1" cellpadding="10" cellspacing="0">
<TBODY>
<TR>
<TD class><B><FONT color="#0000cc"></FONT></B>Hunter<BR></BR><BR></BR></TD>
<TD class>
<P><FONT color="#009900">Today</FONT><FONT color="#ff00cc"> </FONT></P></TD>
<TD class><FONT color="#009900">Tomorrow</FONT></TD>
</TR>

<TR>
<TD bgcolor="#dddddd" class><B><FONT color="#990000">***</FONT></B></TD>
<TD bgcolor="#ddffdd" class><FONT color="#ff0000">
<MCE:SCRIPT type="text/javascript"><#comment></#comment></MCE:SCRIPT>
<BR></BR><BR></BR></FONT></TD>
<TD bgcolor="#ddffdd" class><FONT color="#ff0000">
<MCE:SCRIPT type="text/javascript"><#comment></#comment></MCE:SCRIPT>
<BR></BR><BR></BR></FONT></TD>
</TR>
</TBODY></TABLE>
</CENTER>
–

This seemed to work OK in an earlier version of Confluence that we were using, but not anymore with 2.10.1.

Hi Darryl,

I have tested your example. It works fine in the latest version of confluence. However the original problem that was reported by Jim is not fixed yet.
Unfortunately we don't have plans to fix this bug any time soon. In general there are a lot of limitations in our Rich Text Editor and some of them are explained in this issue . Perhaps you would want to comment there.

Anatoli.

In our case, I had the following bit of JavaScript and HTML:

{html}
<script type="text/javascript">
function addOn() {
var submission=document.getElementsByName("submission") ;
var oldsubmission = submission[0].value ;
var component=document.getElementsByName("component") ;
var image=document.getElementsByName("image") ;
var updateversion=document.getElementsByName("updateversion") ;

var newsub = new Array() ;

if (oldsubmission != '') {
newsub.push(oldsubmission) ;
}

var out = '' ;

if (image[0].value != '') {
newsub.push(component[0].value + "+" + image[0].value) ;
}

if (updateversion[0].value != '') {
newsub.push(component[0].value + "=" + updateversion[0].value) ;
}

var i = 0;

submission[0].value = newsub.join("\n");
}
</script>

<p><form name="subformat">
<table border="0">
<tr><td>Component:</td><td><input type="text" name="component"></td></tr>
<tr><td>Target Image:</td><td><input type="text" name="image">
<tr><td>Update Version:</td><td><input type="text" name="updateversion">
<td align="right"><input type="button" value="Add Below" onClick='addOn()'></td></tr>
</table>
</form>
</p>

{html}

When somebody had Rich Text set as their default (I know – real users always use Wiki Markup), or when somebody switches from Wiki Markup to Rich Text and then back, you end up with this mess:

{html}
<br />function addOn() {<br /> var submission=document.getElementsByName("submission") ;<br /> var oldsubmission = submission[0].value ;<br /> var component=document.getElementsByName("component") ;<br /> var image=document.getElementsByName("image") ;<br /> var updateversion=document.getElementsByName("updateversion") ;<br /><br /> var newsub = new Array() ;<br /><br /> if (oldsubmission != '') {<br /> newsub.push(oldsubmission) ;<br /> }<br /><br /> var out = '' ;<br /><br /> if (image[0].value != '') {<br /> newsub.push(component[0].value + "+" + image[0].value) ;<br /> }<br /><br /> if (updateversion[0].value != '') {<br /> newsub.push(component[0].value + "=" + updateversion[0].value) ;<br /> }<br /><br /> var i = 0; <br /> <br /> submission[0].value = newsub.join("\n");<br />}<br />

Component:
Target Image:
Update Version:

{html}

In other words, totally broken HTML. This is in 2.7.1. Can anybody verify the bug still exists in 2.8.1? Feel free to cut and paste my HTML.

Same issue in 2.7 - this has been on-going for some time. I see a number of tickets about this same issue and I intend to comment on each of them because this needs fixing! Vote!

We've also seen this issue. In fact, it seems that (at least with 2.6.1) all of the HTML enclosed within an

<p>
The tags will disappear.
</p>

Switch to the Ritch Text Editor, and then switch back to the wiki text editor, and the <p> tags will be gone.

BTW, we've seem a similar problem with the {code} macro, where it removes all line breaks and from code enclosed in the macro.

We consider these bugs very serious, to the extent that they make the Rich Text Editor rather dangerous.

Hi Tom,
I've attached a .txt file with mixed HTML and wiki markup ("Confluence Rich Text HTML Error.txt"). A few of my users create some pretty gnarly combinations of HTML and wiki markup (mostly because the Confluence table notation does not provide enough flexibility and control for them). But, from a quick scan of this, it looks like all HTML tags and wiki macros are scoped correctly (matching start/end HTML tags and matching wiki macros).

If you paste this into a Confluence page using the Wiki Markup editor, the preview of the page looks as expected (see attached file "previewAfterWikiMarkup.gif"). There should just be an error because the SecDev_AgraFort.JPG file is not attached to your page.

But, if you switch to the Rich Text editor, and then switch to the preview, you will see something that looks like the other attached screenshot ("previewAfterRichText.gif").

Let me know if you see problems in the HTML/wiki mix that is causing the problem. I'd love to get my heavy HTML users to switch to the wiki markup so I could avoid problems like this, but they need to have a lot of control of the format and appearance of the output.

Thanks,
Jim

As far as I can tell, this works. Can you please give an example of exactly what contents you have in the html macro, exactly what the user editing using the rich text editor does, and exactly what goes wrong?

Thanks,
Tom