Click after a wrapped line in an inline editor may not set cursor in the right place.

[RaymondLim]

1. Start Brackets with word wrap on.
2. Open an inline editor with some long lines. I used CSSInlineEditor.js file in brackets source and open inline editor for _getSelectorName on line 182.
3. Resize the window width narrower until you see line 78 in inline editor starts to wrap.
4. Try to select some word or set cursor after line 78.

Result: Selection or cursor may be off. You can see the same anomaly by selecting "endIndex" on line 79, and start resizing window to see the selection highlight moves around.

[RaymondLim]

Can't reproduce it in sprint 37, only reproduce it in master.

[njx]

I can't repro it on my Mac, will try on Windows.

[njx]

To me, medium priority

[peterflynn]

@RaymondLim Do you think this could be the same issue as #7258? It's also related to problems clicking on text in an inline editor with word wrap...

[RaymondLim]

Yes, I think it is related and it may also be related to #7202. But I can't say the same issue as #7258 since that one is reproducible on Mac and this one is only on Windows.

[RaymondLim]

Removing Win Only label since I can reproduce it on Mac if "Show Scroll Bars" is set to "Always". I can also reproduce it in CSS inline editor. So it has nothing to do with invoked JS function in the same file and/or located before the line used for invoking inline.

[njx]

Makes sense - I've seen a couple of commits in CM recently related to management of the vertical scrollbar, so I can imagine there are bugs related to wordwrap there.

[RaymondLim]

@njx Good news!
I just confirmed that this was introduced with this commit in CM codemirror/codemirror5@365911d#diff-e8acc63b1e238f3255c900eed37254b8.

[njx]

Hmm, that's interesting...that change only seems to deal with the height, not the width, so I wonder why it would affect it.

[RaymondLim]

Well, this issue is caused by resizing the width, which in turn changes the height of the inline editor because of line wrapping. If I revert this change, I don't see any refreshing in the inline as I resize the width. ie. highlight rectangle sticks with the selected word all the time and I didn't notice any flickering in that rectangle. So I wonder whether some async refresh ops on our end also contribute to the issue.

[njx]

Yes, but I'm not sure why changing the height calculation as that commit does would change the behavior of word-wrap (i.e., the horizontal sizes are the same in either case, so the horizontal layout shouldn't change).

I'm pretty sure we do refresh both the outer and inner editors on each size change, but don't have a clear idea for how that would affect this.

BTW, I noticed that if I turn off line numbers this doesn't seem to reproduce, so I do think it is somehow related to the gutter sizing, though I still can't really figure out why that would affect this.