-
Bug
-
Resolution: Duplicate
-
Medium
-
None
-
5.0.1
-
None
-
Windows 7, 64-bit
- Create a page containing an html/xml code block containing the following content:
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> </settings>
- Save the page
- Double click on the code block, copy the contents into the clipboard.
- Paste the clipboard into an editor (I use textpad) and save to ~/.m2/settings.xml.
- Run any Maven command, causing it to use settings.xml. Maven will complain:
[FATAL] Non-parseable settings C:\.m2\settings.xml: start tag unexpected character \ua0 (position: START_DOCUMENT seen <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"\r\n\ua0... @2:2) @ C:\.m2\settings.xml, line 2, column 2
It seems that Confluence is inserting unicode characters into the clipboard (at the end of each line) which causes Maven to fail.
Expected behavior: The clipboard should contain the exact same characters that were put into the code block in the first place.
Workaround: Edit page, copy contents of code block into clipboard. Contents are now correct.
I am setting priority to critical because this issue results in data loss/corruption for the typical use-case.
Workaround:
As the No Format macro doesn't allow for double click selection, one potential solution is to disable the Code Macro (by going to Confluence Admin > Manage Add-ons > System Add-ons) and then create a user macro called something like 'code' with the template: <ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[ $body]]></ac:plain-text-body></ac:macro>, which means that whenever someone goes to create a code macro, they instead make a No Format macro.
- is duplicated by
-
-
- Closed
-
- mentioned in
-
Page Failed to load
[CONFSERVER-28319] Unexpected unicode characters inserted into code block
I would like to point out that four prety much the same tickets are open:
Bug CONF-31446 Doubleclicking Code Blocks Copies Spaces as Non-Breaking Spaces Minor OPEN 5 Actions
Bug CONF-28319 Unexpected unicode characters inserted into code block Major OPEN 10 Actions
Bug CONF-28223 Allow to disable the 'Hint: double-click to select code' 'feature' Minor OPEN 4 Actions
Bug CONF-24952 Mangled clipboard copy of code block after doubleclick
No worries. Regardless of the priority of this issue I hope that we're able to address it for you soon.
I think your definition of data loss is too narrow (excludes the possibility of data corruption, which is just as serious as data loss), but I'll leave things be because there is a relatively simple workaround.
Thanks for reviewing the issue nonetheless. It's good to see you revisiting issues on a regular basis.
Hi Gili
Thanks for the update, I appreciate the sentiment of your comment but I don't feel that this issue matches the definition of a critical issue as per our usage guidelines (you can read the full set of guidelines here: https://confluence.atlassian.com/display/DEV/JIRA+usage+guidelines):
Critical: Crashes, loss of data, severe memory leaks. Examples of critical bugs:
"After saving an edited page, all pages created by that user get erased"
"After a user changes his email address, his profile gets erased"
For this particular issue there is also a simple workaround: Edit page, copy contents of code block into clipboard. Contents are now correct.
With these things in mind I believe that "major" is the correct priority for this issue.
Regards
Steve Haffenden
Confluence Bugmaster
Atlassian
Steve,
I disagree. Confluence is causing data loss. We pass in a value, confluence corrupts it, and we get out a different value.
Hi Gili
I'm going to regrade this issue. Because the problem that you describe does not cause confluence to crash, does not cause users to lose data and does not cause any serious memory leaks I don't believe that this is a critical issue.
I'm going to mark this as a major.
Regards
Steve Haffenden
Confluence Bugmaster
Atlassian
I examined this under a hex editor. In the "bad case" Confluence is inserting 0xC2 0xA0 0xC2 0xA0 at the beginning of each line. In the "good case" it inserts 0x20, 0x20 instead.
@mtran / @Minh Tran- This issue causes enormous losses of time and can break applications. The total of the votes for
CONF-31446,CONF-24952andCONF-28319suggest this is the most widely-reported of all open Confluence bugs. Might it be addressed soon?