Problem with wordwrap in nested CodeMirror

[njx]

In Brackets, to implement our "inline editor" feature, we create line widgets that contain nested CodeMirror instances. The nested CMs are height: auto, and we automatically set the size of the containing line widget to match the height of the nested CM, e.g. if the wrapping changes. This used to work fine, but has a bug in CMv4.

Here's a standalone repro case:

1. If on Mac, in System Preferences > General set "Show scroll bars:" to "Always" (or use a mouse); on Windows, this shouldn't be necessary
2. Open https://gist.github.com/njx/9905035 in Chrome
3. Resize the window a bit to get the line widget to appear (not sure why this is necessary)
4. Double-click on "background" in the line widget to select it
5. Resize the window narrower until the "font-family" line starts to wrap
6. Slowly resize the window wider just past the point where the "font-family line" should no longer wrap

Result:

• The text at the end flickers between wrapping and not wrapping.
• The selection below the wrapped text jumps around between lines as you resize.

It seems as though CM's idea of what text is wrapped is different from the browser's own line wrapping.

This problem seems to have been introduced by 2007b3c.

Also note that on Mac it only reproduces if scrollbars are always visible, so it's probably somehow related to the layout of the fake scrollbar somehow (though in this case the scrollbar should never be visible because the widget is always sized to the content height, it could be that there's some timing problem where the scrollbar is briefly visible).

[njx]

(Updated description to point out that on the Mac this only happens if scrollbars are set to always visible.)

[njx]

(Updated description again - it looks like the commit that actually introduced the bug was 2007b3c.)

[njx]

Another data point: it seems like the problem occurs even if you take out the explicit code to update the line widget height and just let the widget node stay auto height as well as the nested editor. (In our case we have to manually set the height in JS because we have other stuff in the inline editor that we need to lay out programmatically, but that doesn't seem to be required to reproduce this issue.)

[marijnh]

Please try with attached patch, which tries to take a different approach (fix the bogus layout, instead of trying to fix the measurements in the face of that layout). It fixed the problem for me on Chrome Linux, but do verify that it also helps in the actual Brackets situation.

[njx]

Yes, that seems to work in Brackets as well. Just out of curiosity, is there a reason why you set the min-height of the sizer to 0 instead of just setting it to docHeight as in the normal case? Or is it that it doesn't matter since the gutter container is always present even if there are no gutters, so it's always safe to just let it set the height?

[marijnh]

My assumption is that this Webkit bug only triggers for auto-resizing editors, in which case the rendered text covers the whole viewport, and there is no need to force a height.

[njx]

That makes sense, although it seems like you'd get into the new code any time the sizer was smaller than the full width of the window, so this code would execute in other cases besides the bug case. That doesn't seem to be causing any problems for us at the moment, but I'm just curious whether there's any risk with this change if it happens to trigger in other situations besides the bug case.

[njx]

Never mind, I guess the sizer is always going to fill the width.

[marijnh]

Indeed, the sizer's width is 100%, so when the test there fails we are dealing with a layout bug.

[njx]

Got it. I'll let you know if we run into any problems, but it looks good so far. Thanks for fixing this so quickly.