Since @codemirror/view version (6.19, maybe 6.18?) hoverTooltip switched position style to absolute, which doesn’t work in my settings, but everything works great in version 6.16.
I’ve quickly glanced thru code and found changes to positioning and size measurement for a tooltip.
I’m sure it has good intents, but is it possible to force positioning to be calculated and displayed as “fixed”?
Do you have a transform style on any parent element of the editor? It will do this if the (fixed-positioned) tooltip doesn’t have the document body as offsetParent, since in that case fixed positioning doesn’t work the way the editor needs it to work (where left/top correspond to actual window coordinates).
Yes, editor might be shown in elements which are using transform but, everything works well in previous version. Can I force the tooltip to be fixed? Or can I do any workaround so it would stay on top of elements?
That is strange. transform will completely change how position: fixed works, and I’m having a hard time coming up with a scenario where it doesn’t break it. What kind of transformed element is this?
we are using some sort of “dynamic scroll box”, and it has position: relative and then we have one more element which change the offsetParent, so we don’t have a transform style. So you are right about overall appropriate implementation, it just happened for us - previous implementation worked perfectly, because hover tooltip was shown ant appropriate position and it was staying about all other elements
That doesn’t change the offsetParent of fixed-positioned child elements.
How?
I work with @1mehal, and just wanted to provide a little more info on where the codemirror editor instance is rendered.
We’ve got it inside a few different DOM elements, and some of them (including an immediate parent), has a position: relative. Because of this, the offsetParent is never going to be document.body, forcing the tooltip to have an absolute position (based on what I’m seeing here: https://github.com/codemirror/view/blob/main/src/tooltip.ts#L242).
In some cases, we do need this position: relative on some of the parents to do correct absolute positioning of other elements on the screen, but this also causes the side-effect of our CM6 tooltips to also be absolutely positioned instead of fixed, which breaks (due to overflows/scrolling).
Is there a way to force fixed positioning instead of absolute positioning? It seems odd that this applies to all editor views that are inside a non-static parent element (without any transforms).
An example of the DOM structure we are working with:
<div style="position: relative; overflow: auto;">
<div />
<div />
<div>
<TheCodeEditorIsHere /> <!-- this editor's offsetParent is the relative div -->
</div>
</div>
Thanks for the help!
Again, elements with position: fixed don’t have their aren’t affected by wrapping relative-positioned elements, when it comes to offsetParent.
But I think I found the issue—Firefox sets the parent of a fixed-positioned element to document.body, Chrome, on the other hand, sets it to null, which my code wasn’t accounting for. Could you take a look to see if this patch helps? (@codemirror/view 6.20.1)