Open jogibear9988 opened 1 year ago
Hopefully someone can help me, to find the root of that problem. Maybe look at the chrome Bug, I already tried to change all the scroll methods, so the debugger is hit, but this did not happen.
I can verify the bug, but without a reproducible sample we cannot help you unfortunately.
Please try to recreate the bug in the monaco editor playground.
How should i recreate in Playground? Maybe it is related if the Monaco Editor is wrapped in a webcomponent?
If I remove the " wordWrap: 'wordWrapColumn'," it does work
Simplified sample once more:
And it works if I remove the wordWrap: 'wordWrapColumn'," from monaco, but I still don't know if it is a monaco or chrome issue
This sample works in Firefox, but also not in Safari.
Click in Line 4 (this already does not work in Chrome) In safari you need to enter some characters in the end of line 4 to cause the issue
Has nothing to do with webcomponents, also breaks in this sample:
You only need to klick into the created monaco editor. With Safari it only breaks if you enter some characters at the end of line 4. With Firefox it works.
If you reset the "scrollLeft" of the element with class "overflow-guard", display is correct again
@hediet Is this enough now to reproduce the bug?
The bug seems to be the following focus call scrolling into view the current cursor location:
setSelectionRange(h, f, S) {
const p = this.c;
let m = null;
const b = N.getShadowRoot(p);
b ? m = b.activeElement : m = document.activeElement;
const L = m === p
, k = p.selectionStart
, I = p.selectionEnd;
if (L && k === f && I === S) {
w.isFirefox && window.parent !== window && p.focus();
return
}
if (L) {
this.setIgnoreSelectionChangeTime("setSelectionRange"),
p.setSelectionRange(f, S),
w.isFirefox && window.parent !== window && p.focus();
return
}
try {
const M = N.saveParentsScrollTop(p);
this.setIgnoreSelectionChangeTime("setSelectionRange"),
p.focus(), // <--- This focus call scrolls the input caret into view
p.setSelectionRange(f, S),
N.restoreParentsScrollTop(p, M)
} catch {}
}
This seems to be because the textarea itself is extremely wide. I was able to fix the bug by applying width: 0 !important
to the following textarea:
<textarea data-mprt="6" class="inputarea monaco-mouse-cursor-text" wrap="on" autocorrect="off" autocapitalize="off" autocomplete="off" spellcheck="false" aria-label="Editor content;Press Alt+F1 for Accessibility Options." tabindex="0" role="textbox" aria-roledescription="editor" aria-multiline="true" aria-haspopup="false" aria-autocomplete="both" style="tab-size: 28.9062px; font-family: Menlo, Monaco, "Courier New", monospace; font-weight: normal; font-size: 12px; font-feature-settings: "liga" 0, "calt" 0; font-variation-settings: normal; line-height: 18px; letter-spacing: 0px; top: 0px; left: 0px; height: 1px; width: 0px !important;"></textarea>
After that, focusing the text area no longer requires scrolling to the right in order to scroll the text caret into view.
@flackr thanks for investigating! Why is this related to wrapping though?
@flackr thanks for investigating! Why is this related to wrapping though?
I'm not sure. I only looked at why chrome was scrolling the textarea in the context of determining whether the scroll was expected. If you make the textarea have a non-zero height maybe you'll be able to see why the wrapping option is changing the position of the focused cursor. It's still possible that there is a bug in the text layout or selection location especially since you're only seeing this issue in chrome.
as I mentioned here: https://github.com/microsoft/monaco-editor/issues/3587#issuecomment-1441530602 it also happens in safari (in a little bit different way)
Right so the browser difference seem to be resulting from different text wrapping in the height: 0
I'm not sure whether the text wrapping differences are bugs or just due to different selected fonts and other metrics. If you want to pursue this could you make a simple test page of the textarea contents and selection in cases where you see different behavior?
Are you up for a PR?
Blaming points to https://github.com/microsoft/vscode/compare/da1406166702eb790c2629f4c0ced8eaa503cc88...2936f3cab8468cc5f4139a23b462313dcb652c9d , very likely introduced by https://github.com/microsoft/vscode/pull/163229
@alexdima will it be fixed?
I think this can be fixed by using overflow: clip
instead of overflow: hidden
on the .overflow-guard
element? overflow: clip
doesn't support any kind of programmatic scrolling, so the p.focus()
call that @flackr linked to above won't scroll the element.
Here's a copy of the repro link above, but with a hacky overflow: clip
fix
Assuming I'm not missing something, is this something the Monaco team could prioritize? This is a pretty frustrating UX bug with a seemingly trivial fix!
Update 2024-06-24: My suggestion above is actually only a partial fix - if the editor is nested inside parent elements with overflow: hidden
, those will potentially scroll too, so the overflow: clip
fix needs to be applied to those parent elements as well. This makes this fix less palatable.
In the p.focus()
call highlighted earlier, can preventScroll: true
be provided, or is the purpose of that call to actually trigger a scroll?
Edit by @hediet See https://github.com/microsoft/monaco-editor/issues/3587#issuecomment-1441530602 for playground lik.
Reproducible in vscode.dev or in VS Code Desktop?
Reproducible in the monaco editor playground?
Additional info
I don't know if the cause is using it in a Webcomponent, or some other setting. Also it only is broken in Chrome (and derivates). It works in Safari and Firefox. I also don't know if it is a Monaco Error, a error of me or a Chrome Bug. Maybe someone can help where we need to look (for example who is responsible for this scrolling). I already also created a Chrome Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1416178
Reproduction Steps
Much more simple example is now below: https://github.com/microsoft/monaco-editor/issues/3587#issuecomment-1441530602
has nothing to do with webcomponents nor my designer. It's a problem when "wordWrapColumn" is set and the line is to long.
1.) Go to (the link is only so big, it contains the content of the designer): https://node-projects.github.io/web-component-designer-demo/index.html?html=%3Cdiv%20style=%22box-sizing:border-box;pointer-events:none;display:grid;position:relative;width:1500px;height:900px;background:rgb(255,%20255,%20255);%22%3E%20%3Cdiv%20style=%22box-sizing:border-box;pointer-events:none;display:inline-block;width:1500px;height:712px;position:relative;grid-area:1%20/%201%20/%20auto%20/%20auto;justify-self:stretch;align-self:stretch;margin:0px%200px%20188px%200px;%22%3E%20%3Cdiv%20style=%22box-sizing:border-box;pointer-events:none;display:inline-block;width:1408px;height:104px;position:absolute;left:50px;top:572px;%22%3E%20%3Cdiv%20style=%22box-sizing:border-box;pointer-events:none;display:inline-block;width:148px;height:417px;position:absolute;left:187px;top:-156.500015px;background:rgb(224,%2031,%2031);%22%3E%3C/div%3E%20%3C/div%3E%20%3C/div%3E%20%3C/div%3E 2.) Switch to Code 3.) Go to the End of Line 4 4.) Enterer some characters
See also this Video: https://watch.screencastify.com/v/tnSRGDiFCvSDwALTzio4
Actual (Problematic) Behavior
Editor is moved outside of the screen via Scroll Left
Expected Behavior
Editor should work as expected
Additional Context
No response