This should absolutely be a bug, not a suggestion. "Intentional design decision" to leave anybody who uses a decent size monitor with a TON of white space on either side of a narrow channel of text, is bordering on insanity.

Please, try and actually use your product in a way that your users would, and see that a table with any more than 10 columns completely shrinks the width of columns down to the point where text is not readable, i.e. 1 word per line. How is this acceptable and "intended"?

What's funnier is zooming out also shrinks the width of the table, leaving even more white space on each side.

How have you got this so drastically wrong?

Why not allowing 3 types of page widths?

• Standard
• Wider (the today's "Full-Width", which isn't one)
• Full-Width (a REAL full width)

Shouldn't be that difficult to implement, right?

"Aid in readability" is a cheap excuse. Fix your product. 

"The issue type has been changed from a bug to a suggestion because the issue is an intentional design decision.  The width of content is limited to aid in readability."

There are a lot of highly talented people using these tools and best practices usually come from bottom-up and daily usage. How about letting the Content Creator experts decide whats best for them, and their users? 

Unless there is some industry study that suggest that huge empty spaces improves readability based on eye movements and brain scans, please let the experts work as best they know, not the best the design team can imagine.

Thank you @John, yes I've made sure to create an empty template using the old trusty editor.

However, the problem applies to everybody's content in our organisation, and it's disappointing that we have to resort to hacks to make our pages readable

@Rolf, there is a dirty hack that some folks have found allows them to keep using the old editor for things it's better at like large tables.  If you have any pages that were built with the old editor (assuming you didn't mass convert everything to the new editor), you can copy one of those, delete all content, then save it as a "template" of sorts.  Copy it for any new page you want to create with big tables.

Don't understand this design decision at all either. Why should the content not simply expand to fit the width of whatever device is being used? I don’t see any purpose whatsoever in limiting the width of the content, as users can adjust their window size to suit their own needs anyway.

We have recently migrated to the cloud version and are struggling with using large tables in Confluence now. Most of my colleagues are facing similar issues and it’s so disappointing that the cloud version has limitations and is more difficult to use than the old version (page width is just one example). I’m concerned that fewer people in our organization will be using Confluence because of these difficulties, which will be a real shame as the tool has been brilliant for us so far, prior to migrating to cloud.

I can get on board with the entire page not expanding to full width for readability (although I would argue that should be up to the user because you already have formats that keep the content in a thinner column), but this should not be the case for tables.

For tables, the whole point of being able to zoom out (or have very wide monitors) is to be able to see the entire table without horizontal scrolling.  I'll admit that tables aren't the sole focus of this issue, but they should be allowed to go truly full width.  There are other table-related issues floating around out there, but assuming none are specifically about truly full width tables, perhaps this one could be changed to focus the issue on tables at full width.

Hi everyone,

The issue type has been changed from a bug to a suggestion because the issue is an intentional design decision.  The width of content is limited to aid in readability.

The ticket is left open to gather feedback for the design teams.

Changing the ticket status comes from a different team so coordinating the timing can be off at times.

Did you see that?

Since today this is no longer a "Bug" :/

You think Atlassian is removing the issue type "Bug" from the entire Jira database?

All other bugs and lack of functionality in the new editor they also classify as "Suggestions".

Thah...

#sticking to conlfuence server until proven unwise

Since I cannot attach a screenshot, let's see if this works: https://physoft.jira.com/wiki/spaces/~john.tolle/pages/2850029597/Not+100+Width+On+Wide+Screens?atlOrigin=eyJpIjoiODZmZjg3NWRkZDdiNGUwYjgwOTkwMzk2MzAyOTAyODkiLCJwIjoiYyJ9

This is still an issue.  To repeat myself (and I just repeated this test)...

In my testing with the new editor, tables (and sections) expand properly from edge to edge with minimal margins on a 1080p 16:10 27" monitor.  That said, if I zoom out in the browser to emulate a larger (wider) display, the issue becomes more apparent the more I zoom out.  Looking at the CSS, this looks to be due to some crazy JavaScript resizing code that actively sets a forced element width rather than using basic built-in CSS like, you know... margins!

Hi eb02c71181db we are still in the process of reviewing this bug, and will definitely reach out for more information.  Thanks!

Label added: CNR = Can Not Reproduce?

Please please please REACH OUT to any of us - we can show you the problem in 3 seconds.

f7ae1d98cc50 Thanks at once for your reply. To bring back status opened this is very good. Believe in good cooperation.

Hi c86da686f5d2 Thank you for the follow up. Please note we are continuing to groom our product backlogs and our primary intention is to ensure we are focusing on ongoing impacting bugs of our customers. We will keep open any that we’ve heard are still problematic, and continue to review how we can incorporate these into our future product roadmap, where applicable. 

As we understand your frustration and will help you address it, we would like to ensure to keep the conversation at a professional level as we are working together towards understanding what areas are still a problem for our customers and what features/product bugs we need to address as part of our Atlassian product roadmap. Please note as per our policy - https://www.atlassian.com/legal/acceptable-use-policy, we would like to avoid inappropriate communications and disparaging Atlassian or our partners, vendors, or affiliates. Thank you for your understanding.

Best, Rebekkah

Looks that Anna is totally unskilled employee because she copy, and paste the same comments into other issues 

• https://jira.atlassian.com/browse/CONFCLOUD-61733
• https://jira.atlassian.com/browse/CONFCLOUD-57252
• etc.

Also, if we look into Anna's activity https://jira.atlassian.com/secure/ViewProfile.jspa?name=65c9b14381b6

It looks that Anna not real person, and looks like a bot which closed issues without reproducing. Your qualification has many questions.

Dear Atlassian team, you should think about hiring employees like Anna, who are not connected with the users.

@Anna, as John mentions, this can be easily reproduced if you zoom out in the browser.

This is one of the blocking issues that holds us back from moving to cloud.

Please re-open this ticket.

Anna, this issue is not visible when looking at a normal 1080p (standard wide screen) monitor at 100% zoom level.  However, if you look at a page with a wider monitor (larger horizontal pixel count) or simply zoom out in the browser, to say, 50%, you'll notice that the "full width" table is no longer full width. 

Hi everyone,
This is Anna from the Confluence team. Thank you for raising this bug and bringing it to our attention. After examining this issue, we weren’t able to reproduce the behavior within our instances. To set the right expectations, we are closing this bug to focus on our upcoming roadmap for all Confluence users.
If this is still an issue for you, please let us know. Thank you again for providing valuable feedback to our team!
Best regards,
Anna

Another vote for this capability.  Working with tables that have more than 15 columns becomes pretty difficult, even on a 24" monitor.  Laptops... forget about it.

In my testing with the new editor, tables (and sections) expand properly from edge to edge with minimal margins on a 1080p 16:10 27" monitor.  That said, if I zoom out in the browser to emulate a larger (wider) display, the issue becomes more apparent the more I zoom out.  Looking at the CSS, this looks to be due to some crazy JavaScript resizing code that actively sets a forced element width rather than using basic built-in CSS like, you know... margins!

In Notion this feature works fine: flicking the Full Width switch makes all pages go full width.

No matter how far you zoom the browser in/out - all content ESPECIALLY LARGE TABLES is shown from left to right without white spaces.

According to the Atlassian policy this is never be implemented 

"Adding attachments on this screen is not supported" 🙄

Is also not helping...

"LONG TERM BACKLOG" - seriously?????

This is a problem making many of my pages impossible to create in the new editor.

Example of a table in the legacy editor:

I had to zoom out in the browser to 67% to make the table fit the screen (height & width) - the table is still READABLE & USABLE on a 24" monitor

That same table in the new editor:

I have to set the browser zoom to 100% to make the table fit the screen width.

I had to zoom out in the browser to 25% to fit the table on one screen.

The table gets compressed and stretches out vertically over multiple screens -> UNREADABLE & USELESS

Conclusion: this bug in the new editor blocks me from making big complex tables

Back luck for me, I do this frequently. Working in an R&D or scientific context, this is my life :/

BUMP UP the priority PLEASE!