Monaco-editor: Providing container for 'overFlowingContentWidgets'

Created on 9 Sep 2016 · 9Comments · Source: microsoft/monaco-editor

When using Monaco in a context where the parent nodes use 'overflow:hidden' the contents from overFlowContentWidgets gets truncated. Unfortunately in our case it's not possible to change the outside context.
Is there a way or could you consider to provide the parent node of the overFlowingContentWidgets div, such that a client could hang it into e.g. <body>?

feature-request

Source

svenefftinge

👍5

Most helpful comment

I tried, but it is unfortunately not so easy, because the position is based on the viewport in tghe rendering context. So the popups show up in odd locations.

svenefftinge on 22 Sep 2016

👍2

All 9 comments

I mean if I could pass a provider for the node where 'this.contentWidgets.overflowingContentWidgetsDomNode' would be attached to, I could atach it to some parent, so it can overflow.
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/view/viewImpl.ts#L281

svenefftinge on 20 Sep 2016

I suggest the following workaround:

the view gets created after each setModel() call.
after each setModel() call you can grab the overflowingContentWidgetsDomNode straight from the DOM and reparent it to the <body>.
maybe this will work for you?

alexdima on 20 Sep 2016

Thank you. I will try tomorrow and report.

svenefftinge on 20 Sep 2016

I tried, but it is unfortunately not so easy, because the position is based on the viewport in tghe rendering context. So the popups show up in odd locations.

svenefftinge on 22 Sep 2016

👍2

I am also hitting this issue and changing the containing structure is very non-trivial. The popover is already being absolutely positioned, it seems like it should not be according to the editor position.

jchomicki on 3 Feb 2017

The positioning strategy can be changed by setting the fixedOverflowWidgets: true option.
With that moving the elements up should be easier, however I managed to fix the overlaying issues by adjusting the z-index of the focussed editor branch.

svenefftinge on 10 Mar 2017

I've just hit this issue as well and I did try setting fixedOverflowWidgets to true. However, it seems like tooltips created via glyphMarginHoverMessage ignores this setting. Is this intentional?

sertand on 9 Aug 2018

+1 same problem here

paranoidjk on 11 Aug 2020

Starting with the next release, there will be a new editor constructor option called overflowWidgetsDomNode. This will be used as a parent node for all editor content widgets that are marked as overflowing.

alexdima on 18 Sep 2020

👍1

Was this page helpful?

0 / 5 - 0 ratings