[Lens] the screen is resized a tooltip is shown

[markov00]

Kibana version:
7.12

Elasticsearch version:
7.12

Browser version:
Chrome

Browser OS version:
Mac OS

Original install method (e.g. download page, yum, from source, etc.):
cloud

Describe the bug:
When the "suggestion" tooltip appears, the Lens screen is shrunk, showing a scrollbar and resizing both the chart and the right panel

Steps to reproduce:

1. Move the mouse over a Suggestion panel
2. When the tooltip appears you will notice the resize event
3. A similar behaviour can happen also when showing the tooltip of a helper icon or when opening a dropdown menu

Expected behavior:
No resize on tooltip

Screenshots (if relevant):

Feb-22-2021.10-27-59.mp4

Errors in browser console (if relevant):
n/a

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[flash1293]

@chandlerprall Could you take a look at that? This is likely the same problem I mentioned here: elastic/eui#4382

But with the scrollbar setting used it's much more noticeable.

[markov00]

A similar behavior seems to happen when opening a dropdown menu on the right panel

Feb-22-2021.11-51-52.mp4

[markov00]

And causes issues also on help tooltips like the following

[flash1293]

The body gets a euiBody-hasPortalContent class for the time tooltips/popovers are open:

.euiBody-hasPortalContent {
    position: relative;
}

If this rule is removed, the scrollbar doesn't appear. For this time, the lens app is slightly scrollable (same as here: #84638)

[flash1293]

It's caused by the screenreader info in the portal for keyboard instructions:

As soon as that's removed, the scrollbar disappears, even if euiBody-hasPortalContent is set on the body

This is the styling:

.euiScreenReaderOnly, .euiScreenReaderOnly--showOnFocus:not(:focus):not(:active) {
    position: absolute;
    left: -10000px;
    top: auto;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

I guess this height of 1px is what's causing the scrolling.

[flash1293]

I might miss an obvious fix here, but I think the best approach would be to but those keyboard instructions inside of the element structure of Lens, not at the end. @myasonik is it absolutely required these instructions are at the very end of the body?

Looking into the dom structure, it wouldn't be too difficult to make it the last text in the document, even if it's not directly in the body, but nested in a bunch of divs.

[flash1293]

Maybe we have to change something about the page layout in general - discover for example has the same problem because of some monaco helpers which are added in the same way:

[myasonik]

is it absolutely required these instructions are at the very end of the body?

No, it doesn't matter too much where the instructions are. We don't want them directly inline because that causes them to be read out twice sometimes but anywhere near the end of the DOM is fine but "near the end" is very flexible.

As you're seeing with the monaco stuff though, this type of thing is often just stuck at the end to try to be out of the way.

[chandlerprall]

@flash1293 in this case, the extra scrollbar is coming from the euiBody-hasPortalContent class on body. Manually adding that class, even without a popover present, triggers the scrollbar.

[flash1293]

@chandlerprall it's only triggered if the euiScreenReaderOnly portal element is appended to the body (plus the euiBody-hasPortalContent class)

[cchaos]

If you can re-create this problem in a Codesandbox with EUI, I can take a look.

[chandlerprall]

That euiScreenReaderOnly comes from Lens, not a portal. The interaction/scrollbar might be a bug or otherwise fixable through EUI, but without a separate reproduction as Caroline mentioned it looks more like a Kibana layout thing.

lens_screenreader_scroll.mov

[flash1293]

That euiScreenReaderOnly comes from Lens, not a portal

@chandlerprall What I meant is Lens is rendering the .euiScreenReaderOnly within a portal (which is appended to the body), and that together with the eui class on the body and the fact that Kibana has a layout which tries to stay at exactly 100% height here, is causing this problem.

If I remove the screenreader element, the scrollbar goes away but for some reason the dropdown of the EUI combo box is shifted (by the amount of space the scrollbar would use):

We are going to check this out in detail on Monday

it looks more like a Kibana layout thing

I agree with that, it's probably some weird CSS/HTML structure in Kibana that's causing this.

[flash1293]

Same problem in Visualize when using the inspector (because it also includes monaco I guess). It's pretty likely a lot of apps have that issue in one way or the other, but it's especially noticable in Lens.

@elastic/kibana-core Any idea how we could resolve this issue on the Kibana level? The problems boil down to "adding an element directly to the body with a non-zero height causes the body element to become scrollable". I played around a little and the following approach looks promising (basically making #kibana-body behave like the body):

• Remove padding-top from body
• Set #kibana-body to position: absolute; top: 0; left: 0; right: 0; bottom: 0
• Give .app-wrapper a margin-top: 98px

[myasonik]

Looping in @elastic/kibana-design too - to make sure we don't bungle a broad CSS change.

[flash1293]

@dej611 Are you currently working on this? As it seems like this issue can't be easily solved in a nice way without low level changes (which I would like to avoid at this point for 7.12), what do you think about moving the screenreader component into the lens root element for 7.12 to take the pressure out of fixing this and opening a separate issue to solve it in a "nice" way?

[flash1293]

Opened an issue for the shifted combo boxes here: #93586
Opened an issue for the scrollable body here: #93587