Dear customers,

Noting your recent comments, I've looked through this ticket and tried to understand why you may be receiving this bug in your Log Analyzer results. This was showing up because our Log Analyzer matching pattern on this issue was set up to be slightly too liberal and has been pulling this bug in as a false positive. I've fixed the pattern so once your Log Analyser receives the new pattern update in the coming days this issue will no longer come up.

Hope this helps, cheers.

Michael Andreacchio

Confluence DC Product Management

Same here. 7.13.7 and getting

Having this in the Log Analyzer with 1 recent occurence in LTS 7.13.7, too.

Same question as Steven Hawes. I just upgraded from 7.4.6 to 7.13.7 and this error appears in my post upgrade log analyzer.

Hi! 

Why would I still be getting this error pop up in my logs in 7.13.2?

A fix for this issue is available to Server and Data Center customers in Confluence 6.15.6
Upgrade now or check out the Release Notes to see what other issues are resolved.

Hi,

During this time if can help, I apply an another workaround (and keep collaborative mode enabled).

You just need to rewrite your BASE_URL on the fly with mod_substitute (Apache):

<Location "/">
 AddOutputFilterByType SUBSTITUTE text/html
 Substitute "s@http://BASE_URL/@https://BASE_URL/@i"
 </Location>

We've had to withdraw 6.15.5, and will release 6.15.6 soon. We'll update this issue once the new version is available. You can find out more about the related issue here: CONFSERVER-58490

Dear customers, 

To those who have upgraded to Confluence 6.15.5, there is a problem with the emoticons fix whereby standard emoticons with dashes in their name (e.g. "green-star" or "thumbs-up") will be incorrectly converted to an unknown HipChat emoticon. If you have upgraded to 6.15.5, please disable the "Confluence HipChat Emoticons Plugin" from "Manage Apps" screen in Confluence's administrator console. I have attached a screenshot showing how to do this, "Confluence HipChat Emoticons Plugin" is a bundled plugin, so please ensure that the "All Apps" option dropdown in the search dropdown is selected. Also, note that "Manage Apps" is accessible through "https://baseurl/plugins/servlet/upm/manage/all". 

If you have not yet upgraded to Confluence 6.15.5, please hold off on doing so while we investigate this further. 

Follow the resolution of this here: https://jira.atlassian.com/browse/CONFSERVER-58490

Thank you to patrick.rohrberg2 for providing the information about this behaviour. 

Hi patrick.rohrberg2,

Could you please send the view page HTML for the "disappeared" emoticons (retrieve this by right clicking the emoticon -> inspect element and then copying the element which has the "emoticon" class on it). Ideally we could see a comparison of the HTML between the viewpage in your production instance versus the test instance (not the entire page, just the emoticon element). 

The storage format that you have included is correct (it would have been converted after page save). 

Affected pages' emoticons disappeared in our test environment, but if you go in edit mode, they are still there and if u save it, everything will be fine.
We are using HSTS, so this could affect how this bug/solution is handled with 6.15.5. Well, im fine with that.

      <p>
        <ac:emoticon ac:name="plus"/>
      </p>
      <p>
        <ac:emoticon ac:name="green-star"/>
      </p>

Hi oliver.kuckertz,

You mention that the view page shows the textual representation of the emoticon, this shouldn't be happening. Would you be able to provide a snippet of the page DOM (right click the emoticon -> inspect element) and the page storage format (... -> View Storage Format). 
For example, the storage format may look like this:

<img class="emoticon emoticon-smile" title="(smile)" src="http://redacted.com/wiki/s/en_GB/8201/594d61d4e19e457994e21ebe83418ed460a84f81/_/images/icons/emoticons/smile.svg" alt="(smile)" border="0" />

And the view format (by accessing the page DOM) may look like this:

<div id="main-content" class="wiki-content">                
        <p><img class="emoticon emoticon-smile" src="/wiki/s/en_GB/8202/c269a9e523458b8ffeb6e574c4d0a88e43f9b4b4/_/images/icons/emoticons/smile.svg" data-emoticon-name="smile" alt="(smile)"></p><p><br></p>                
</div>

And could you also send a screenshot of the broken emoticon? Also, how did the emoticon appear before upgrading to 6.15.5?

Given that the emoticon is displaying correctly in edit mode (you don't have a broken draft in this case), it should also be displaying correctly in view mode. 

Hi cyril.michaud, patrick.rohrberg2 and oliver.kuckertz,

Apologies for the lack of update. I have updated the description of the ticket with details about the fix. In short, viewing pages with emoticons should work after the upgrade, and the fix to the page storage format is applied as pages are resaved.

The issues with the 6.15.5 release notes and issue statuses should also be resolved now I believe. Let us know if you have any more questions.

Thanks.
Niraj Bhawnani
Senior Development Team Lead, Confluence Server

A fix for this issue is available to Server and Data Center customers in Confluence 6.15.5
Upgrade now or check out the Release Notes to see what other issues are resolved.

I found that this issue is fixed on my installation, but affected pages require manual work. Observations are:

1. Affected pages' emoticons (thumbs up in my example) disappear entirely, and are replaced by their textual representation. Browsers show HTTPS as secure.
2. Opening the editor (live collab) shows the correct emoticon. Browsers show HTTPS in mixed content mode.
3. Saving in the editor, without making changes, properly restores the emoticon in the page. HTTPS is shown as secure again.
4. Opening the editor again fixes the mixed content mode warning, HTTPS is still shown as secure.

Well - there is something wrong with the release Process..
According to https://jira.atlassian.com/browse/CONFSERVER-58321?jql=project%20in%20(CONF)%20AND%20issuetype%20in%20(Bug%2C%20%22New%20Feature%22%2C%20Improvement%2C%20Suggestion)%20AND%20fixVersion%20%3D%20%226.15.5%22%20AND%20status%20in%20(Resolved%2C%20Closed%2C%20Done%2C%20%22Released%20to%20Server%22)%20AND%20resolution%20%3D%20Fixed%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC

or there a just some Tickets with the wrong state

https://jira.atlassian.com/browse/CONFSERVER-51661?jql=project%20in%20(CONF)%20AND%20issuetype%20in%20(Bug%2C%20%22New%20Feature%22%2C%20Improvement%2C%20Suggestion)%20AND%20fixVersion%20%3D%20%226.15.5%22%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC

Confluence 6.15.5 is available for download but...

• release note cannot be viewed "JIRA project doesn't exist or you don't have permission to view it." - https://confluence.atlassian.com/doc/issues-resolved-in-6-15-5-973477291.html
• this issue (and others) is still "Waiting for release" on release 6.15.5 and unresolved

Can we upgrade or not ? Is the fix included in the release ? Will corrupted pages be automatically fixed ?

@Fabian Gottschall:

Thank you; will try that - as soon as Atlassian releases this fix.

Hallo Mathias,

it's look like stored in content. "..." -> View Storage Format

Could you test Addon/App "search and replace" on staging system to fix it ?

https://marketplace.atlassian.com/apps/1212823/search-and-replace?hosting=server&tab=overview

Do you have other Ideas ?

for us this solved the issue and fixed the current pages 

https://jira.atlassian.com/browse/CONFSERVER-52441?focusedCommentId=1984277&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1984277

<VirtualHost 0.0.0.0:443>
 Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains;"</VirtualHost>

OK, stumbled into this problem as well.

Only experienced the problem, because I had to rename my server (different base URL).
This causes the (additional) problem, that the URLs referencing the emoticons now (still) point to the old server - which isn't available anymore, ... you get the idea.

So, main question for me is:
Will there be an easy way to fix all the invalid <img src="..." ...> back into <ac:emoticon ...>
(in pages already stored with that URLs instead of macro references)?

Otherwise, that problem will pop up again, when you have to move / rename the server.

@Patrick Rohrberg: thanks for that hint, it indeed fixes the broken display temporarily.

For Apache Users: The module headers is required for this workaround.

HSTS Header will do the trick
It wont fix the http:// links, so there is still a "Mixed Conent"-Warning, but your Clients will always use https to get the Content!

nginx

server {
 listen 443 ssl
...
location / {
....
add_header 'Referrer-Policy' 'same-origin';
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
  }
}

Apache

<VirtualHost 0.0.0.0:443>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains;"
</VirtualHost>

Same here, happened in the worst moment ever: we (IT department) just got our management to purchase the licenses for all users for Confluence while this bug appeared in our presentation. A fix should appear immediately.

Also here, really annoying! And a problem if it persists, i.e. if there is no cleanup of affected pages together with the fix!

Up to now, we thought of Confluence as a sometimes headstrong, but robust tool... This breaks our confidence!

Hi everyone,

Just dropping an update on the status of this ticket. Thanks for your interest in this ticket and for being patient with us while we work on this. We have done our investigation and are currently actively working on a fix for this issue. We expect to have a fix out in Confluence 6.15.5 which is due to be released soon.

Thanks,
Niraj Bhawnani.
Senior Development Team Lead, Confluence Server
Atlassian

We have a lot of changed urls now...https emoticons changed to http....when will this issue be fixed? Mixed content on a ssl only website is not so nice.

And then manually fix all the failed pages. Will Atlassian pay for my time or provide a migration fix when they finally get round to fixing this issue.

This is not an option. Atlassian has to automatically fix all corrupted pages when they finally provide a fix. No way someone can identify and fix the hundreds of affected pages manually in our confluence. 

I was about to disable Collaborative Editing, now I won't.

I will just have to watch this cancer spread across a product that had previously won a good response from users and erode the trust cultivated through intra-team collaboration.

And then manually fix all the failed pages. Will Atlassian pay for my time or provide a migration fix when they finally get round to fixing this issue.

"We recommend you use SSL, but we won't support you doing it, and by the way, our software doesn't even work very well under SSL."

I've disabled Collaborative Editing and now my users can't rename their pages.  We really need an ETA on this fix.

dsp1 - Thanks for your comment. We don't believe these issues are related but cannot confirm until we investigate further.

I was curious if the CONFSERVER-58180 Tomcat issue mentioned was related because it also has an nginx work around I'd be willing to try. We're currently on v6.8.2 and on-hold testing v6.15.2. I can't go live with this one.

Yesterday i saw the first time this issue in our confluence (6.15.2).

Where is the fix? (and why is this issue not assigned to anyone?)

CONFSERVER-58180, another emoticon issue just was fixed. Any chance this will be in the next release then?
We have very unsatisfied clients.

also "emoticon emoticon-question" won't work

<img class="emoticon emoticon-question" title="(question)" src="http://DOMAINNAME/s/en_GB/8100/4410012ac87e845516b70bc69b6f7a893eabaa5a/_/images/icons/emoticons/help_16.svg" alt="(question)" border="0">

For workaround #1 - We procured Confluence and upgraded specifically for capabilities such as collaborative editing. So asking us to turn off collaborative editing is NOT a workaround. Should we ask for our money back. 

For workaround #2 - That isn't a workaround either. As soon as the page is edited again - it will be broken again.

Neither workaround is satisfactory. 

PLEASE FIX.

This is what my document looks like. Very disappointing this basic issue is allowed to continue whilst I'm being pushed onto the Cloud offering. I'm less than convinced. This despite me championing the use of Confluence over other options within our teams. Frankly it's embarrassing. 

2 years and still no fix? wth?

PLEASE FIX THIS....

This is affecting us too and is as a result of upgrading from 6.7 to 6.15.2, following the security advisory of 20 March 2019.

We're using SSL, but not with a proxy.

We're getting the same behaviour whereby what should be https is rendered as http.

Please fix this.

Turning off collaborative editing resolves partially this issue. But collaborative editing is key feature and turning it off is disadvantage

1)add emoticon to page (OK)
2)edit page and update  emoticon are not broken(OK)
---- but existing broken emoticons in pages are not resolved (NOT OK)

Editing every page isn't something we have time or motivation to do - need a software fix or some other more elegant workaround.

We noticed the url's weren't redirecting properly - so we invested some time in adding a rule to the urlrewrite.xml file

Added this rule:

{{ </rule>}}
{{ <rule enabled="true">}}
{{ <name>Force HTTPS example</name>}}
{{ <note>Automatically redirects all http requests to port 8443.</note>}}
{{ <condition type="scheme" operator="equal">^http$</condition>}}
{{ <to type="permanent-redirect" last="true">https://confluence-example.com:8443/</to>}}
{{ </rule>}}

in /app/confluence/confluence/WEB-INF/urlrewrite.xml

THIS DID NOT WORK. Unclear why. 

Hi @Lee,

The 'storage format' is a xml-like format that is used by the tools internally to store confluence pages.
It is, indeed, the way, pages are found in the database as well.

A common way to edit the storage format of a page, is by using the app Confluence Source Editor.
It makes storage format accessible on every page in the editor through a " < > " -button to the upper right.
A word of warning, though: This is an administrative debugging tool and it's probably not recommended to leave it enabled permanently.
Its easy to break a page if editing the storage format without proper caution. (As you can probably imagine.)
So make sure to disable the app after you are done.

So the fix would be:

• Go to and edit a page with missing emoticons
• Open the storage editor
• Search for all the <img ...> tags where the emoticons would be
• For each, edit the src="http://..." attribute's value to start with https://...
• Save the storage format and save the page

You might have noted, this does require you to go through every emoticon on every page that is important for you.
So, this version of the workaround is not really feasible on any kind of scale.

After that, you do start looking at regular, automatic and scripted page updates. (Which might still have the drawback of screwing with page histories quite heavily.)

Of course, all these measures are not pretty and a proper fix of the software much more desirable. (As is the nature of bugs.)

Please fix with new release a.s.a.p - this is impacting our users since we did an upgrade a few weeks back.

Unforgivable that your QA did not catch this.

Suggested workaround #2 says:

"For Confluence 6.14.x, editing the storage format to point the broken URL from HTTP to HTTPS able to temporarily fix the issue"

Do you guys want to rewrite that sentence is some language we can all understand ?

Specifically - what do you mean by "storage format".
What are the steps to complete the workaround.

If you going to take the trouble to propose a workaround - perhaps make it clear what steps needs to be done. 

Is this some mysql db hacking ?

For us this is a critical bug too - please fix as soon as possible...

With every day we loose more information in our pages...

Thanks

Please fix this bug as soon as possible! The purpose of the icons like  or  is lost by editing the page... It is not just an emoji (the emoji has a purpose).

this is a critical bug, fix it ASAP. Every day with this bug creates more confusion and work for our users.

hey guys fix it ASAP, we are going to migrate hostname and apply reverse proxy in our instance and this is critical issue.

The summary of this issue does not capture the actual failure. It's not just changed to an image tag, but for all https users to an image tag with an invalid URL! --> it corrupts the page content, the emoji are not visible any more!

This issue blocks updates past 6.13 for everyone using https. It's critical to fix this.

Please fix this.

6.13.2 also affected.

We changed our base URL recently. Most emoticons and images have now a reference to our old base url and can now not be loaded properly.

It breaks in 6.14 SSL and so also security from the whole system. Please increase severity from this bug.

is it any workaround (global) for this issue?

Add 6.2.4 to this list

What a mess. We plan to upgrade to 6.14.2

Workaround

1. Disable Collaborative Editing - To avoid the issue from occurring

After this workaround our instances were not able to move pages in hierarchy and checkboxes on pages stopped working. We had to enable collaborative mode back. When collaborative mode was re-enabled, page editing broke. Confluence restart was required. So not a workaround for us, but more like service breaker.

We have this same issue in some Confluence instances!

Running HTTPS proxy before services is just mandatory in secure systems.

Breaking page content is not a minor issue. This must be fixed as critical bug.

With the 6.14.x behavior that not only changes the icon to a <img> tag, but also corrupts the URL from https to http (which confluence instances that are available via https will not be reachable), this issue should not be "Severity Minor" any more.

This corrupts the content of confluence pages! 

This bug must be addressed fast! Especially with the added problem of 6.14.1 that generates mixed content on sites running on https!