Scrolling issues in editor
complete
Dustin Smith
scrolling is increasingly erratic in editor. Often scrolling completely ineffective, contents move slightly and then jump back to their original places
Log In
Michael Wood
This issue is still occurring. I'm not sure if I should open a new ticket, but this is still an issue. As Shannon Greywalker stated nearly 3 years ago:
"The problem seems to revolve around Markdown articles that have multiple images and/or embedded HTML (such as <details> blocks to create collapsible sections, or <br> elements to control vertical spacing inside a bullet or number list, or inside a table cell)."
Please fix the Markdown editor when there is embedded HTML in the page. This scrolling issue makes creating and editing these pages quite painful.
D
Document360 Support
complete
D
Document360 Support
Since the issue does not occur anymore, we are marking this item as "Complete" for now. Please reach us if you have any queries. Thank you!
Van Neeley
Leaving this comment 8/31/2023
Likewise, I am still experiencing erratic scrolling behavior within editor mode. It's making editing frustrating and time-consuming. Will there ever be any fix for this?
Wim Vermunt
Please make an option so users can revert back to browser controlled scrolling.
Kylee Duede
This is still an issue with scrolling. If I am editing further down the page and go to scroll to see the preview, the contents jump around and sometimes does not scroll all the way down unless I click the scroll bar itself.
Thiru
under review
Thiru
complete
Thiru
Shannon Greywalker Tim Fletcher Dustin Smith we have addressed this issue and the same has been rolled out in March release. Kindly request you to validate this at once and let us know if any concerns.
Shannon Greywalker
Thiru: I have been watching for a return of this behavior and it is STILL happening as of this datestamp. (May 18, 2022)
The problem revolves around markdown documents that contain some combination of admonition boxes (Info, Warning, Error, Private Notes) and images and code blocks and bullet/number lists.
A plain text document (headings and paragraphs) exhibits no such issues. But something about your synchronization between the rendering pane and the source markdown pane goes crazy when you have some combination of images, code blocks, admonitions, and lists. Which unfortunately (lol) comprises a large percentage of the articled in our KB.
BTW if it makes any difference at all in your testing/reproduction scenarios, we do routinely use the
Width=""
value in newly-inserted images. As a standard, we reduce all images wider than 600 px to a value of Width="600"
for improved readability of rendered content. (Full-width images tend to obscure the reader flow of of prose content.)Shannon Greywalker
We noticed this right away. It's hugely problematic. The obvious workaround--closing the split-panel preview in the Markdown Editor--has its own unique problem in that your cursor focus is no longer accurate, and you must type some junk text (such as jfjfjfjf) and then find and remove that junk text just to be able to use the Markdown Editor after you've closed the split panel.
FWIW, the problem seems to revolve around Markdown articles that have multiple images and/or embedded HTML (such as <details> blocks to create collapsible sections, or <br> elements to control vertical spacing inside a bullet or number list, or inside a table cell).
Load More
→