@Rory Apperson Seems alright for me at the moment, although it was doing some funky stuff earlier. Didn't get around to submitting it to support because I was quite busy, but I got a massive error message and couldn't work out why.
I have been reading through the comments hoping to find help with how slow the editor is for us. Is there a slow/fast setting in the configuration that I have missed? Does anyone have any guidance? Typing in this comments box works perfectly, but when I type in the editor, the letters do not appear until I have typed for about a second. I must be doing something wrong. I only see this lag in the editor and not on other websites or Atlassian's own website. I have deleted all my cookies and restarted my computer, but the editor is still very slow. I have tried Chrome and Safari. Is it possible there is a better browser that is more suited to the editor?
And does anyone know how to get rid of the Page Tree macro problem where page titles wrap even though they aren't very long? Some of them wrap even though they are very short. There is no setting in the macro for wrapping after two or three words, but that happens sometimes. Maybe it only happens for me and no one else.
@[deleted] I get the slow text entry too. I could be wrong but I think it might be a result of the amount of memory Confluence pages use. It's infrequent, but it happens. I get it on deleting text, too. I have to delete slowly or highlight and then delete text because holding `Backspace` requires guesswork to know when to release it.
And I think there should be a Jira ticket for text-wrapping Page Tree titles. I did see a reason given for it somewhere, but I forget where they both were.
So... no. You're not alone! If you have the energy, report them as bugs. And, uh, just get used to it...
The status is "LONG TERM BACKLOG" --- I think that is an improvement over "Gathering Interest", but it is very hard to tell in Atlassian's public-facing jira project for Confluence Cloud.
As I noted in the comments on that bug, https://jira.atlassian.com/browse/CONFCLOUD-66613 appears to be the same issue, on a wider scope than just columns. (But it was closed as a duplicate of 66771)
@Tom Crowley I have just tested Chrome memory usage while (1) viewing a page, (2) editing a page in the old editor, and (3) editing a page in the new editor.
Chrome sucked up maybe 100MB when first viewing a page, but this dropped back to around 30MB after the page loaded because there wasn't much for the client side to keep working on.
What was interesting to me was that both the old and new editors seemed to swallow about the same amount of memory when editing a page. This began at about 160MB when first opening a page for editing, but it dropped back to about 120MB when the content had loaded. As I say, I saw no real difference between the memory used by either editor.
I have decided that I don't mind typing slowly in the new editor and waiting for it to catch up. The new colours and emojis improve my day far more than working efficiently. I love that I can colour my technical tables with a purple background and add a thumbs-up emoji. I believe that will make a world of difference to my customers—and they are sure to feel happier when they see a smiling emoji next to a complex SQL statement.
I always like to look on the bright side of life. While I am waiting for the editor to catch up, I now have plenty of time to send thank-you emails to the developers at Atlassian.
The delays have also given me plenty of time to explain to my customers that their technical documentation is now a work of art owing to the extraordinary creative brilliance of the Atlassian team. My customers have asked me why the images are now much larger than they should be, and fuzzy, and misaligned, but I think I managed to win them round with a bright yellow table and ROFL emoji.
If only some other users, whose names I shan't mention, took the same positive approach you do. Sadly they left before you had a chance to influence them for the good...
That is a great shame, @Tom Crowley. It sounds like the other person needed to get themselves some more Atlassian contribution badges to help cheer themselves up.
On a separate note, I'd like to say how thoroughly funny I find it when the new editor temporarily shows me an older version of the content when I open a page for editing. I'll be honest with you—and I don't want to sound critical—but my first reaction is to almost poo myself because I think I've lost some important content, but then the actual current content reappears, and I see the funny side.
I have decided it's a clever feature—like when you're watching a TV series and you get a quick review before the next episode begins. Once I've got over the initial shock, I laugh and say, "There you are, you naughty little content. It's no good hiding. I knew you were there all along."
@[deleted] / @Tom Crowley I filed a support ticket with Confluence over my issues with the slow typing in the editor and the messed up rendering of the TOC and Page Tree macros (sometimes it doesn't render or if it renders, the pagination of the content is all messed up).
First of all. What an awesome support team they have. I've been impressed with how professional Vinicius has been with me. The notes he took of my case are super impressive. He keeps me informed of his research on a daily basis and even offered to do a Zoom session so he could see the problems himself.
I showed him that difference between the two editors. It appears that the new editor sends every keystroke to the servers and when the latency is above 200ms, I can see the delay. If you do the same in the older editor, it appears that they batch multiple keystrokes and then send the data to the server in a batched job (possibly in the background) so I don't observe any delays.
You can run the above experiments using Chrome's developer tools, where you can monitor the network traffic as you type. I plan to do more experiments this weekend to see if I can provide proof that it is the v2 editor and not my network or computer environment.
Thanks @Monique vdB. One small request: would you be able to ask whoever looks after the docs to move the "Last modified" div to the top of the article? It looks like it's a template thing, so they should be able to change it.
Because it's a long page, it would make it easier to be able to periodically check in and see when it was last updated without having to scroll to the bottom of the page to see whether it had been changed since the last time we checked.
Sending every keystroke to the server does not seem very optimal indeed. It would be better to wait until there is no keyboard activity for, say, 100ms or so before sending the next batch of keystrokes to the server. That would avoid wasting resources unnecessarily, especially network resources, not to mention the effect on faster battery depletion on mobile devices, and so forth. That kind of waste may seem negligible but it rapidly adds up.
@Jean-Michel Decombe I want to make it clear that I don't know for certain how many characters are being collected before transmission. I am just making an educated guess based on the amount of traffic I see in Chrome's network tab when comparing it to the legacy editor. It certainly feels a lot less buffering is happening on the client (Chrome) before dispatching to the server.
I don't know enough about front-end technologies to be able to debug this in more detail but the annoyance may get me motivated enough to learn how :-)
I have done more experiments this weekend. I've figured out that when I type fast (my normal speed), characters begin to lag. If I type very slowly, one character at a time, they show up fine. Using Chrome's Dev Tools network tab, I can see that when I type slow, there is barely any traffic. When I typed fast, the analytics-web-client starts to send traffic.
One small sentence "this is typing very fast", sent 4 packets, which took over 600 ms (total). I believe this is where the problem is.. the logic for analytics is having problems, sending too often and with long delays (over 100ms per send)
Here is a video showing my problem and how the analytics is the traffic being sent when the hiccups occur
That's a great page, thanks Monique. It is a helpful summary of many (but not all) bugs and limitations of the new editor. Can you please confirm whether Atlassian plans to acknowledge (and address) the other bugs and limitations reported in these threads and also in bug Jira issues? For example, how can we know that the word-wrapping bug in the Page Tree macro is being considered if it isn't on the list? The entry in the conversion table suggests the macro converts completely (but that therefore ignores at least one overlooked bug). And how do we know that the many image-handling bugs and limitations are being addressed when they aren't on the list? You get the idea. Perhaps you are already preparing an entirely different resource to list all the known bugs and limitations (including those reported by customers) and are simply waiting to share it in due course.
As an aside, it seems the first paragraph on the Roadmap page was so good that it was used a second time further down the page (with only two word changes).
188 comments