[JENKINS-28022] Build description longer than 30 chars has hex zero width space added

[jenkins-infra-bot]

We use a Groovy script to write the package version into the build description of a job after it completes. Users then copy this from the Jenkins UI and paste it to perform a deploy. I have discovered occasional strange issues with this where what seems to be a valid version number is not found by our deploy system. Eventually I figured out that Jenkins is inserting a

​

in the string if it exceeds 30 chars. This is invisible (obviously) in the UI but gets captured when the text is selected and copied/pasted (at least with Chrome on MacOS). This is a problem because this copy-paste workflow has been embedded here for several years, and a recent Jenkins upgrade has thrown this entropy into it

---

Originally reported by owenmehegan, imported from: Build description longer than 30 chars has hex zero width space added

• status: Closed
• priority: Minor
• component(s): core
• resolution: Fixed
• resolved: 2021-01-20T21:01:52+00:00
• votes: 19
• watchers: 25
• imported: 2025-11-24

Raw content of original issue

We use a Groovy script to write the package version into the build description of a job after it completes. Users then copy this from the Jenkins UI and paste it to perform a deploy. I have discovered occasional strange issues with this where what seems to be a valid version number is not found by our deploy system. Eventually I figured out that Jenkins is inserting a 

​

 in the string if it exceeds 30 chars. This is invisible (obviously) in the UI but gets captured when the text is selected and copied/pasted (at least with Chrome on MacOS). This is a problem because this copy-paste workflow has been embedded here for several years, and a recent Jenkins upgrade has thrown this entropy into it 

• environment: Jenkins 1.596.1, 2.124

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Why is this assigned to me?
  

Why is this assigned to me?

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Workaround: Copy it from the build index page.
  

Workaround: Copy it from the build index page.

[jenkins-infra-bot]

tinro:

• Original comment link
• Raw content of original comment:

  Anyone looking at this problem? We are using copy-paste workflow and encountered this problem
  

Anyone looking at this problem? We are using copy-paste workflow and encountered this problem

[jenkins-infra-bot]

owenmehegan:

• Original comment link
• Raw content of original comment:

  tfennelly do you have any thoughts on this? In Chrome this feature does not actually cause the text to wrap, so we get zero width spaces in the string and nothing else in return, it seems.
  

tfennelly do you have any thoughts on this? In Chrome this feature does not actually cause the text to wrap, so we get zero width spaces in the string and nothing else in return, it seems.

[jenkins-infra-bot]

owenmehegan:

• Original comment link
• Raw content of original comment:

  I take it back - if the build description is just a steady string of alpha characters, it seems to wrap as intended. But when we set the description to the version string that we generate internally (our use case for this), it doesn't wrap at 30 chars. Maybe this is because we always have . and + in the string, among other non-alphanum characters. I just wish there was a better way to get the text to wrap nicely without screwing up the string when we copy and paste it. I had to add a bunch of defensive code to our deploy system so it wouldn't choke on these strings.
  

I take it back - if the build description is just a steady string of alpha characters, it seems to wrap as intended. But when we set the description to the version string that we generate internally (our use case for this), it doesn't wrap at 30 chars. Maybe this is because we always have . and + in the string, among other non-alphanum characters. I just wish there was a better way to get the text to wrap nicely without screwing up the string when we copy and paste it. I had to add a bunch of defensive code to our deploy system so it wouldn't choke on these strings.

[jenkins-infra-bot]

tlopespt:

• Original comment link
• Raw content of original comment:

  I ran into this issue when adding a docker image name to a build's description, which is copy-pasted as input to a pipeline, since the image name was roughly 32 chars long, it was crashing docker with "Invalid reference format", we resolved this problem by sanitizing the pipeline input with:
  
  image = image.replaceAll("[^-a-zA-Z0-9:._]", "")
  
  thus removing the extra chars.
  

I ran into this issue when adding a docker image name to a build's description, which is copy-pasted as input to a pipeline, since the image name was roughly 32 chars long, it was crashing docker with "Invalid reference format", we resolved this problem by sanitizing the pipeline input with:

image = image.replaceAll("[^-a-zA-Z0-9:._]", "")

thus removing the extra chars.

[jenkins-infra-bot]

bwalding:

• Original comment link
• Raw content of original comment:

  owenmehegan - I would completely support you taking on a fix for this - it kills me a little inside every time someone asks me why their deploy didn't work because they sent a corrupted image tag (and I'm not randomly sanitising input against this - as that is yielding to the forces of darkness).
  
  CSS support for word wrapping is sufficiently straightforward - we should just use it. 
  

owenmehegan - I would completely support you taking on a fix for this - it kills me a little inside every time someone asks me why their deploy didn't work because they sent a corrupted image tag (and I'm not randomly sanitising input against this - as that is yielding to the forces of darkness).

CSS support for word wrapping is sufficiently straightforward - we should just use it. 

[jenkins-infra-bot]

gtirloni:

• Original comment link
• Raw content of original comment:

  We've faced this issue on Jenkins 2.8.4 with the GitHub PR Builder plugin where we add the PR's URL to the description. People copy and paste it into their browser's window and, instead of going to the page, Chrome/Firefox won't consider it a URL and instead search for that value.
  

We've faced this issue on Jenkins 2.8.4 with the GitHub PR Builder plugin where we add the PR's URL to the description. People copy and paste it into their browser's window and, instead of going to the page, Chrome/Firefox won't consider it a URL and instead search for that value.

[jenkins-infra-bot]

encounter:

• Original comment link
• Raw content of original comment:

  We were able to work around this issue by adding the following to our custom theme JS:
  
  insertZeroWidthSpacesInElementText=function(){}
  
  

We were able to work around this issue by adding the following to our custom theme JS:

insertZeroWidthSpacesInElementText=function(){}

[jenkins-infra-bot]

patrickdepinguin:

• Original comment link
• Raw content of original comment:

  Problem still exists in Jenkins 2, e.g. 2.124.
  
  We see it not at fixed widths, but at every space of the description string. _See below output, where the actual contents are shown with either xxd or od.
  
  In xxd you see extra bytes 'e2 80 8b' and in od you see 'b nul vt' (342 200 213).
  
  echo "(BR: ​5c12ee9f, ​SW: ​28d0325c, ​BLD: ​60.776) " |xxd
  00000000: 2842 523a 20e2 808b 3563 3132 6565 3966 (BR: ...5c12ee9f
  00000010: 2c20 e280 8b53 573a 20e2 808b 3238 6430 , ...SW: ...28d0
  00000020: 3332 3563 2c20 e280 8b42 4c44 3a20 e280 325c, ...BLD: ..
  00000030: 8b36 302e 3737 3629 200a .60.776) .
  
  echo "(BR: ​5c12ee9f, ​SW: ​28d0325c, ​BLD: ​60.776) " |od -ac 
  0000000   (   B   R   :  sp   b nul  vt   5   c   1   2   e   e   9   f
            (   B   R   :     342 200 213   5   c   1   2   e   e   9   f
  0000020   ,  sp   b nul  vt   S   W   :  sp   b nul  vt   2   8   d   0
            ,     342 200 213   S   W   :     342 200 213   2   8   d   0
  0000040   3   2   5   c   ,  sp   b nul  vt   B   L   D   :  sp   b nul
            3   2   5   c   ,     342 200 213   B   L   D   :     342 200
  0000060  vt   6   0   .   7   7   6   )  sp  nl
          213   6   0   .   7   7   6   )      \n
  0000072
  
  
  

Problem still exists in Jenkins 2, e.g. 2.124.

We see it not at fixed widths, but at every space of the description string. _See below output, where the actual contents are shown with either xxd or od.

In xxd you see extra bytes 'e2 80 8b' and in od you see 'b nul vt' (342 200 213).

echo "(BR: ​5c12ee9f, ​SW: ​28d0325c, ​BLD: ​60.776) " |xxd
00000000: 2842 523a 20e2 808b 3563 3132 6565 3966 (BR: ...5c12ee9f
00000010: 2c20 e280 8b53 573a 20e2 808b 3238 6430 , ...SW: ...28d0
00000020: 3332 3563 2c20 e280 8b42 4c44 3a20 e280 325c, ...BLD: ..
00000030: 8b36 302e 3737 3629 200a .60.776) .

echo "(BR: ​5c12ee9f, ​SW: ​28d0325c, ​BLD: ​60.776) " |od -ac 
0000000   (   B   R   :  sp   b nul  vt   5   c   1   2   e   e   9   f
  (   B   R   :     342 200 213   5   c   1   2   e   e   9   f
0000020   ,  sp   b nul  vt   S   W   :  sp   b nul  vt   2   8   d   0
  ,     342 200 213   S   W   :     342 200 213   2   8   d   0
0000040   3   2   5   c   ,  sp   b nul  vt   B   L   D   :  sp   b nul
  3   2   5   c   ,     342 200 213   B   L   D   :     342 200
0000060  vt   6   0   .   7   7   6   )  sp  nl
213   6   0   .   7   7   6   )      \n
0000072

[jenkins-infra-bot]

patrickdepinguin:

• Original comment link
• Raw content of original comment:

  Workaround suggested by encounter indeed works.
  
  The JavaScript function insertZeroWidthSpacesInElementText is defined and called from war/src/main/webapp/scripts/hudson-behavior.js and indicates that this is actually a feature.
  
  It was introduced by tfennelly in commit cb9036c4552 and refined in b31bb1cc1c5.
  
  tfennelly, could you give input on this issue, please?
  

Workaround suggested by encounter indeed works.

The JavaScript function insertZeroWidthSpacesInElementText is defined and called from war/src/main/webapp/scripts/hudson-behavior.js and indicates that this is actually a feature.

It was introduced by tfennelly in commit cb9036c and refined in b31bb1c.

tfennelly, could you give input on this issue, please?

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  I asked in CSS fix to prevent table content from breaking out of table and align small images for Google Chrome. #3377 that the author investigates whether a similar approach could be done for this. No response. Perhaps one of the watchers here feels up to the task?
  

I asked in #3377 that the author investigates whether a similar approach could be done for this. No response. Perhaps one of the watchers here feels up to the task?

[jenkins-infra-bot]

woldemar:

• Original comment link
• Raw content of original comment:

  We had just encountered same problem once we started using Build Name Setter Plugin.
   Can confirm that workaround provided by encounter does the job - makes build names copy-pasteable.
   As far as I can see this is only reproducible in Build History panel. Everywhere else names of builds were displayed without ​​ in HTML.
  

We had just encountered same problem once we started using Build Name Setter Plugin.
Can confirm that workaround provided by encounter does the job - makes build names copy-pasteable.
As far as I can see this is only reproducible in Build History panel. Everywhere else names of builds were displayed without ​​ in HTML.

[jenkins-infra-bot]

fatcash:

• Original comment link
• Raw content of original comment:

  Hi, thank you for the suggested workarounds. Pardon my inexperience, do I need to have a custom theme to put encounter's JS line? It won't work with stock theme?
   Also waiting for the complete solution, it stole a lot of hours to find the invisible character. Btw, for description the character appears after 30 char and for name (the bold text) its after 20.
  

Hi, thank you for the suggested workarounds. Pardon my inexperience, do I need to have a custom theme to put encounter's JS line? It won't work with stock theme?
Also waiting for the complete solution, it stole a lot of hours to find the invisible character. Btw, for description the character appears after 30 char and for name (the bold text) its after 20.

[jenkins-infra-bot]

markhu:

• Original comment link
• Raw content of original comment:

  Still a problem in Jenkins 2.198 as of September 2020. Duped by JENKINS-40663 
  

Still a problem in Jenkins 2.198 as of September 2020. Duped by JENKINS-40663