Viewport issues with CM 6

We are have a number of issues related to viewports, specifically when the viewport is less than the full document.

  • Built-in browser search doesn’t find text that is clipped by the viewport (naturally), this leads to some inconsistent results and confusion for users. We can’t just use an editor extension for find because we have multiple editors on the page at once and users want to perform finds across all of them.
  • Every once in a while (don’t have a repro case yet), we see to get into a state where the viewport stops updating as the document scrolls, leaving large blank areas on the page and a broken experience. This could be something on our side of course.
  • Certain browser extensions don’t work right, like “Grammarly”, which I guess would depend on all of the editor contents being in the DOM.

I understand the motivation for the viewport feature, but it also doesn’t seem like the cases where we are running into this have editor content that is all that large, they usually are at most 200-300 lines of code.

It would be great if there were some controls over the viewport behavior, like the ability to set a minimum size in lines or characters. Is there already a way to do that? Browsing the code makes it seem like all the values are hard-coded.

-Wiltse Carpenter, Observable Inc.

Viewporting is a rather fundamental aspect of the way the library is designed (much of the complexity analysis in the implementation depends on it) and not something that can be turned off. (I keep getting CM5 support requests where people set viewportMargin: Infinity and then are surprised when the editor gets slow. I want to avoid that failure case this time.)

The way this breaks browser search is very annoying, but a trade-off that seems unavoidable with this design.

A repro case for viewport bugs would be very useful. Your issue might have been solved by @codemirror/view 0.19.9, which makes this more robust.

Browser plugins that just jump into pages and start messing with editable DOM are, from the perspective of an editor maintainer, a really terrible idea and not something I’m very sympathetic to.

Thanks for the reply. Making plug-ins work is not a requirement for sure, but I mention it anyway because it did come up from a user complaint. And to be precise, it is the DOM element visibility clipping that affects us, not the maximum size, so it is not directly a performance issue. If we force the view printing flag to be true, we don’t have the problem.

Is it possible to set the viewport margin now? My scenario is to use browser to print the code page. When the codemirror element is long, the lower half of the container is blank when printing,I need to set close viewport Margin to make print work

No. But the editor listens to the beforeprint event and should render the entire document when it gets that. Which browser are you testing with?

sorry forgot to reply

Our scenario is based on chrome headless printing on the server side, and the server-side screenshot service does not call the print method.

The final solution In this scenario, we add the following code

try {
           (view as any).viewState.printing = true;
           (view as any).measure();
         } catch (e) {
           console.error('codemirror defaultPrintMeasure error', e);
         }