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.

Quality reviewed by Matthew Erickson.

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