When the highlight code text is too large, it can cause the browser to lag and even crash

[torisgzhang]

Describe the issue/behavior that seems buggy

When I highlight the code text is too large, causing the browser to crash, open the browser DevTools found that the plugin will be a large number of text into the dom, too much dom caused the browser to crash and crash, please ask me when I need to highlight a large number of code text what should I do to avoid this problem?

Sample Code or Instructions to Reproduce

Expected behavior

I'm testing this in the demo on the official website by pasting in a lot of code text, and I'm also having this problem, the demo page stutters and I can't do anything with it.

Additional context

[joshgoebel]

How large is too large?

[torisgzhang]

How large is too large?

I don't know the exact text size threshold, but this problem occurs when you exceed about 3 MB...

[joshgoebel]

3mb is a lot. This sounds like a browser problem. We only do the highlighting, which might be CPU heavy... BUT once the HTML is on the page if the browser can't scroll it properly, that's browser issue - the browser is just failing to deal with all the HTML.

[damocles-s]

3MB 已经很多了。这听起来像是浏览器问题。我们只进行突出显示，这可能会占用大量 CPU 资源...但是，一旦 HTML 出现在页面上，如果浏览器无法正确滚动，那就是浏览器问题 - 浏览器无法处理所有 HTML。

Perhaps supporting virtual scrolling would solve this problem?

[joshgoebel]

virtual scrolling

What is that?

[damocles-s]

virtual scrolling

What is that?

maybe just like The configuration item in codemirror5: "viewportMargin" can only render the content in the currently visible view.

[joshgoebel]

@allejo Does this mean anything to you? Should we modify the CSS or just add some code that restricts the limit one can paste - I don't think we need to allow people pasting more than a small amount of text anyways with the demo.

I don't think there is any real problem/bug with the library here... but it might be nice if we at least prevented people from breaking the demo by dumping 3mb on it.

[joshgoebel]

"viewportMargin" can only render t

You're in charge of your own HTML, if you want to wrap the pre/code in some other HTML or style it some specific way with CSS, that's all up to you - not a decision the library makes. Rendering so much text the browser can't show it without some special hacks is definitely an edge case.

If there is some HTML/CSS trick here for others who might want to render so much text we'd be more than happy to have a Wiki page explaining the topic and fix.

[allejo]

oof, 3MB of text is a lot for a browser to handle with scrolling... 🤔 Yes, there are ways of making a "virtual" scrollable area when dealing with such large amounts of text. However, I don't think I want to go down the route of supporting that much highlighting on a demo page (i.e. we're not a browser IDE/editor). What's the use case of highlighting such large amounts of text on our site?

I can, however, raise a warning or prevent large amounts of text from being copy/pasted into the text area to prevent large amounts of text from causing a browser crash.

As an aside, I'm going to move this issue to the website repo and we can continue discussions there.

[damocles-s]

“viewportMargin”只能渲染t

您负责自己的 HTML，如果您想将其包装pre/code在其他 HTML 中或使用 CSS 以某种特定方式对其进行样式设置，这完全取决于您 - 而不是库做出的决定。渲染如此多的文本，如果没有一些特殊的技巧，浏览器就无法显示它，这绝对是一种边缘情况。

如果这里有一些 HTML/CSS 技巧可供其他可能想要渲染如此多文本的人使用，我们非常乐意有一个 Wiki 页面来解释该主题并进行修复。

So, why can't we solve the problem of supporting the rendering of large amounts of text? Large text will also occur when using plug-ins. Why not support it if we only ban it on the demo page? I think this is not difficult to do.

Because I encounter scenes that require rendering a large amount of text, which may be 3M, 5M or 10M. My current solution is to render part of the file slice for the first time, and then render the next part when scrolling to the bottom.

And I have observed that the span tag of the DOM node generated by the plug-in will always exist and increase. Browser lag is bound to happen. I think plug-ins should avoid this situation.

[allejo]

I think there's a bit of a disconnect happening here. My understanding is that after pasting 3Mb of text, the demo page on the website starts lagging/freezing/crashing. Yes, this can be fixed with virtual scrolling.

However, I don't understand WHY you're pasting 3Mb worth of text onto the demo page? The demo page exists so you can see examples of what you're code will look like in terms of syntax highlighting and color schemes. This page isn't a full-blown editor that is supposed to handle large amounts of code.

[joshgoebel]

I have observed that the span tag of the DOM node generated by the plug-in will always exist and increase.

Not sure what you are referring to here.

So, why can't we solve the problem of supporting the rendering of large amounts of text? ... I encounter scenes that require rendering ... 3M, 5M or 10M

So far it doesn't sound like an "in scope" problem... our library at it's core does one thing well - we take code and generate HTML - which the browser is then responsible for rendering. We provide simple CSS themes that work for most use cases. If by "virtual scrolling" you mean some mix of CSS/JS that creates some type of browsing widget/pager within the browser - thats complexity we're not interested in adding or maintaining in core. It's an edge case.

But no one is stopping you from solving this problem and sharing your knowledge here and on the wiki or publishing a plugin/library/widget that takes the HTML we generate and lets browsers more easily deal with it. I'm curious to see if you come up with anything interesting. Good luck.