[Bug] Mouse click incorrectly sets the caret position

Reproducible in vscode.dev or in VS Code Desktop?

• Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

• Not reproducible in the monaco editor playground

Monaco Editor Playground Code

const customElement = document.createElement('div');
customElement.style.height = '100%';
customElement.attachShadow({mode: 'open'});

const customContainer = document.createElement('div');
customContainer.style.height = '100%';
customElement.shadowRoot.append(customContainer);

document.getElementById('container').append(customElement);

const editorRef = monaco.editor.create(customContainer, {
	value: `let wrapper = document.createElement('span');
wrapper.setAttribute('class', 'wrapper');
let icon = document.createElement('span');
icon.setAttribute('class', 'icon');
icon.setAttribute('tabindex', 0);
let info = document.createElement('span');
info.setAttribute('class', 'info');`,
      language: 'javascript',
});

Reproduction Steps

No response

Actual (Problematic) Behavior

I created a MonacoEditor which has issues with highlighting text and setting the caret in the desired position when clicking with the mouse, and I can’t figure out what’s going on.

I added a few console logs as an example, and for instance, I get:

// log1
mouseX: 376
mouseColumn: 16

// log2
mouseX: 223
mouseColumn: 23

What could be interfering with the correct position of the caret in the editor? How could it be that a click further to the right return a lower column number? The deviation is not consistent or proportional either. If I click in the same place, I do get it in the same position. But clicking in one place can have +2 columns wrong, in another to the right have about +6 columns wrong, and further to the right the caret can be even positioned -7 columns in the other direction (like in the example above).

Expected Behavior

Clicking in the editor correctly positions the caret

Additional Context

No response

UPDATE: I found out the issue is when using the editor inside a shadowDOM

[janarvaez]

@janarvaez Did you find a fix or workaround? I’m facing the same issue and using monaco inside a shadowDOM is a requirement for me

I have 2 workarounds.

1. have the container outside the shadowRoot passed as children through a slot. This works fine since the slotted container is actually outside, but wrapped and styled inside the shadow.
2. Wrap the whole editor inside an iframe, but depending on your setup, this could be harder to achieve (although isolating the editor in an iframe prevents other issues, like having multiple editors with different languages rendered at the same time).

[lucasMarioza]

The workaround 1 worked but I figured it out my actual problem. I had one external style from an ancestor component(outside the shadowDOM) that was setting font-variant: tabular-nums. For some reason if monaco was rendered outside the shadowDOM this style was not an issue, and if it was inside the shadowDOM not even remeasureFonts fixed the issue.

I suppose that somehow it is not considering styles coming from outside the shadowDOM during the font measurements, or something like that.

In my case removing this style was not a problem, so I sticked with that solution.