I seem to be experiencing this issue with Confluence 2.10.3 and FF3/IE7. I tried making the change to seraph-config.xml mentioned above and still have the issue. Is there a workaround for this? Our users are completely out of the water if they cannot switch between rich-text and wiki-markup.

I opened CONF-19035 for reference.

Hi Nicolaas,

This is likely to be because IE8 is not a supported browser for 3.0.2.

It will be fully supported in 3.1 - see CONF-15413 for details.

Cheers,
Mark

Hi guys

I'm on 3.0.2. Using IE8 my <RICH TEXT> tab is not available. It is available in FF3.5.5.

At the office I'm using 10.x and it works fine.

Should this issue be reopened or a new issue get logged?

Also, the fix for 2.10.1 is not the same as the workaround, so if you are experiencing issues after performing the workaround an upgrade may still be successful.

Regards,
Andrew Lynch

Hi,

With 2.10.1 now out the recommended approach to deal with this bug is to upgrade to Confluence 2.10.1.
The workaround was suggested as an interim solution until we were able to release the fix for this bug.

Regards,
Andrew Lynch

I modified my /wiki-textarea.vm. I also set my base url to https://wiki.behaviorcorp.org, that is the external address. The rich text editro still does not work. It does work fine internally at the address http://bcwiki

Attached is my seraph-config.xml (prior to the update). It had to be changed to make 2.10 work regarding this issue. More information may be found at CSP-22535 which we closed since the bug identified had a simple workaround. Unfortunately this issue may have made the workaround to be no longer viable. I am reviewing and experimenting with the proposed workaround to this issue to determine if it can be combined with the other workaround. However, it is essential that the final solution work with SSL being handled by (software) Apache or by external gateway devices (hardware Cisco et. al.) since they are more efficient at handling SSL and we typically hide application servers behind firewalls and expose them only through some type of front end for data center security. We only run the app server within the data center under SSL if there is sensitive data which needs to be protect from internal access. Typically, SSL is needed only for login but we determined that remaining in SSL for subsequent editing operations was perfectly acceptable. Regardless of SSL use or not, we still prefer using some sort of gateway (Apache) to hide and provide flexibility for accessing app servers.

Hacking the wiki-textarea.vm as described gets the Rich Text editor working again (we run Confluence behind mod-proxy with Apache2) if the user in question is accessing the Wiki using the URL set as BaseURL in the admin console.

There is still an issue because now our users have to access Confluence using the fixed "BaseURL" if they want edit to work. Previously (Confluence 2.9.2) you could use any of the domain names that resolved to our instance and edit happily.

So this is still annoying – since everything worked a-ok with Confluence 2.9.2 – the upgrade to 2.10 regresses a previously working Apache2/Confluence configuration, even with the wiki-textarea.vm patch we are still backwards a step...

Tested fix with Confluence behind Apache 2, without our recommended ProxyPreserveHost On setting.

IE6, IE7, Safari 3, FF2 and FF3 all good.

Hi Andrew,

I just tried the wiki-textarea.vm fix, and it works!

Thanks

Philippe Muller