Issues with tooltip above/below calculation

v6
1

I’ve noticed a couple of issues with the way the tooltip above/below position is calculated, particularly while scrolling:

  • In this example the tooltip isn’t aware of the search panel, so it doesn’t flip to above the selection until the selection reaches the bottom of the editor, behind the panel.
  • In this example the tooltip doesn’t appear when the cursor is on the second line, but setting arrow: false fixes it.

Also, when scrolling up and down, perhaps the tooltip could return to its original side once there’s room again?

I can open a GitHub issue if that would be appropriate for any of these.

2

These patches should help here.

1 Like
3

Thanks for the patches, those seem to be working nicely.

I was able to get the behaviour I was looking for (keeping the tooltips constrained within the visible code area vertically, but allowing them to extend out of the container horizontally) with the addition of this tooltipSpace calculation:

tooltips({
  parent: document.body,
  tooltipSpace(view) {
    const { top, bottom } = view.scrollDOM.getBoundingClientRect()

    return {
      top,
      left: 0,
      bottom,
      right: window.innerWidth,
    }
  },
})
4

Unfortunately the first patch has caused tooltips for lint gutter markers to no longer be displayed, as they’re outside the “visible” area (see the lint example for a demonstration).

Assuming panels can only be at the top and bottom, I’d be happy with continuing to use editor for the left and right extents of the visible area, if that makes sense.

5

I don’t think that would be the correct fix. If a tooltip is on actual content that is hidden behind the gutter, its tooltip should be hidden. I’ve instead added an option to tooltips that turns off the hiding, and use that option for the gutter tooltips.

1 Like