Are breakout width values automatically generated when pasting Markdown into Confluence?

[Sumate S_]

Hi,

I am investigating a layout issue when pasting Markdown into Confluence.

Environment

- Confluence

- Microsoft Edge

- Markdown content maintained in .md files

- Markdown content copied and pasted into the Confluence editor

Problem

When Markdown containing fenced code blocks is pasted into Confluence, the code blocks are converted correctly.

However, some generated code blocks extend beyond the expected page layout, even when the source content is not particularly large and does not contain unusually long lines.

The original Markdown does not contain any width-related settings.

Additional observations

During troubleshooting, I noticed indications that width-related attributes may have been generated for some page elements. Examples include values such as:

- width: 760

- breakout width: 760

- breakout width: 1011

I did not explicitly define any of these values in the source Markdown.

Because of this, I suspect that width-related attributes may be generated during Markdown conversion or page rendering.

The issue has been observed in Microsoft Edge. I have not yet tested other browsers.

Questions

1. Does Confluence generate or store width-related attributes for code blocks?

2. Can breakout width values such as 760 or 1011 be generated automatically?

3. Could editor or browser size influence the generated code block width when content is pasted?

4. Is there a supported way to reset generated width settings and return to the default responsive behavior?

5. Has anyone experienced similar issues when importing or pasting Markdown into Confluence?

I found discussions about Markdown conversion limitations and table layout issues, but I could not find anything specifically related to breakout width values being assigned to code blocks.

Any information would be appreciated.

Thank you.

[Gabriela - LeanZero · Accepted solution]

Hi @Sumate S_, Confluence does store it, and the editor writes it unasked. I pasted a fenced markdown block into a Cloud page, published, and read the page back over the API: it came back with a breakout mark of mode wide, width 760, which in storage shows up as breakoutMode and breakoutWidth parameters on the code macro. I set neither.

The block itself has no width attribute. A codeBlock in ADF carries only language, uniqueId, localId, wrap and hideLineNumbers. The width lives on a separate breakout mark, and the schema allows that mark only at the top level of the page, so a block nested in a layout column or a table cell has nowhere to attach one.

Both of your numbers come out of the same normaliser over top-level blocks. A block with no mark gets a width of 760, or 1800 if the page appearance is full width. A block already carrying mode wide but no number gets backfilled to 1011, which is 760 x 1.33. Neither needs anyone to have touched a width setting, and an 1011 points at an element that was already wide before the number got written.

The mark renders at min(its own number, container), which is why only some of yours stick out. 760 is the text column, so it is invisible: on my page that block measured 760 beside a 760 paragraph at a 1600px window, and 590 beside 590 at 1100. 1011 inside a 760 column is the one that overhangs. So the window moves what renders, though I saw nothing Edge specific, and I did not test whether it moves the number that gets written.

For the reset, the block's own width control has a centered state that strips the mark, and Atlassian's code block doc names the three icons centered, medium-width and full-width. On my site the block gets drag handles in place of that button, and dragging writes a new number, it does not clear the mark. Which of the two you have depends on the rollout. In bulk: GET /wiki/api/v2/pages/{id}?body-format=atlas_doc_format, drop the breakout mark from the marks array, then PUT the same id back with status, title, the ADF as a JSON string and version.number one higher. That stuck across a republish for me.

Read the number off one that actually overhangs before you do any of that. If it says 760 and still hangs over the edge, something else is going on.

You are not the first. The camelCase spelling is breakoutWidth, no space, and searching that finds this one with breakoutMode wide and breakoutWidth 1800 on a code block nobody touched, and Andrew Chang's with the same two parameters landing on panels.

[Sumate S_]

Hi @Gabriela - LeanZero ,

Thank you for the detailed investigation and explanation.

It is very helpful to learn that Confluence can automatically generate and store breakoutMode and breakoutWidth values

I also appreciate the information about removing the breakout mark through the API. It is good to know that there is a way to reset these settings in bulk if necessary.

One point I am still unsure about is whether the resulting overflow of some code blocks beyond the expected page layout is considered expected behavior or a product defect.

From your experience, does Atlassian consider this behavior to be working as designed, or would it be worth raising a support ticket as a potential bug?

Thank you again for your help.

[Gabriela - LeanZero]

Hi @Sumate S_, the render is working as designed, and there's an open ticket saying so from the other direction. CONFCLOUD-84735 has Atlassian treating it as the bug when a stored breakout width fails to get applied, "causing content to render within the default fixed-width area (~760px) despite the editor rendering it at the full breakout width". Your 1011 is the one that overhangs. That is the stored width being honoured, which is exactly what the ticket is asking for, so an overflow complaint gets closed. It's the Excerpt macro there rather than a code block, so I'm reading across elements.

The filable part is the write, not the render. A breakout mark landing on a code block you never configured, out of markdown carrying no width, is the bit nobody has an explanation for.

If you do go ahead, only site admins and product or billing admins can open a support ticket. That is what stopped Andrew Chang in the panels thread, and Atlassian tried to reproduce his and couldn't, so put your own repro steps in front of the symptom.

[Sumate S_]

Hi @Gabriela - LeanZero ,

Thank you for the clarification.

This answers my original question. I now understand that the rendering behavior itself is working as designed, and that the more interesting question is why breakoutMode and breakoutWidth are written when the original Markdown contains no width information.

I appreciate all the investigation and references you provided.