feat(Popper): add mouse events for popper content

[thatblindgeye]

What: Closes #1457

Preview build - Tooltip

Two new mouse events were added to the Popper component, both to resolve the above issue and for other components that use Popper to potentially utilize these events.

I also updated the default exitDelay for the tooltip with an explanation. Below is a video for the behavior when exitDelay={0} (technically it works). I only chose a value of "300" to match the entryDelay, but if anyone has a default they'd prefer it can be tweaked.

Tooltip.with.0.Exit.Delay.mov

Additional issues:

[patternfly-build]

Preview: https://patternfly-react-pr-7399.surge.sh

A11y report: https://patternfly-react-pr-7399-a11y.surge.sh

[jessiehuff]

Nice! This is exciting to see. @mcoker @mcarrano do either of you know if there are any defaults or guidelines in terms of exit delays?

[mcarrano]

I don't off the top of my head and would need to research this. But what's there now feels pretty good.

[mcoker]

@jessiehuff I don't know either, it's not anything we've defined in core. Our flyout menu may also have an exit delay.

[nicolethoen]

LGTM

[tlabaj]

@jessiehuff I know at one point Zack had updated our delays for tooltip. It was changed to 0?

[tlabaj]

@jessiehuff @mcarrano here is the tool tip PR that changed the delays previously. #5746
In that PR we discussed whether changing the default is breaking as well since it would change behaviour in applications. It was decided it was ok and more of a bug fix for the tooltip.

[tlabaj]

This may be considered a breaking change.

[thatblindgeye]

@tlabaj if this would be considered a breaking change I can revert the exitDelay default back to 0 and add that update as something to make with our breaking change release. I think at least having the prop description be what it's been updated to should help and inform consumers about it in the mean time.

[tlabaj]

@tlabaj if this would be considered a breaking change I can revert the exitDelay default back to 0 and add that update as something to make with our breaking change release. I think at least having the prop description be what it's been updated to should help and inform consumers about it in the mean time.

I don't know that it would be considered breaking. @mcarrano with the tooltip change you said the exit delay update was warranted. How do you feel about a change here?

[mcarrano]

I think I'm confused about what this PR is doing. Is Popper a component that is exposed to the consumer? Do you mean Popover?

[thatblindgeye]

This PR mainly resolves the issue of keeping tooltips active when a mouse hovers over the actual tooltip contents rather than only the trigger. Tooltip just uses Popper under the hood, so I had to make an update to Popper to implement this feature.

I had also updated the exitDelay prop on the Tooltip due to the behavior seen in the video from my original comment (though that behavior is less because of the exitDelay being too short and more because the exitDelay occurs quicker than the entryDelay does). I do think having the exitDelay by default be longer than 0ms is worth making an update for at some point, though, just to ensure by default users have enough time to hover the tooltip should they need to.

[tlabaj]

Ok, I was thinking the change was in popper for some reason. My mistake. Now that I see it is in tooltip, PR #5746 had changed the exit delay from 100 to zero. So, I don't know that we want to increase it here. @mcarrano what are your thoughts?

[jessiehuff]

If the exit delay is zero, would the user be able to hover over the tooltip or would it interfere (like Eric's example above shows)? I'm wondering if the tooltip would disappear before they're able to get to it? Ideally for Level AA compliance, tooltips should be persistent on hover. (WCAG 1.4.13)

[thatblindgeye]

You are able to hover the tooltip with an exitDelay of 0, but since the entryDelay is longer it causes that effect of the tooltip starting to hide and then re-appear when you hover it. Setting both entry and exit delays to the same number, or making the exit delay longer, resolves that visual issue.

[mcarrano]

I don't know why we set the exit delay to 0 in the past, but seems to me that the entry and exit delays should be consistent. Can we just make them the same? Do you see any problem with this @tlabaj ?

[tlabaj]

I don't know why we set the exit delay to 0 in the past, but seems to me that the entry and exit delays should be consistent. Can we just make them the same? Do you see any problem with this @tlabaj ?
@mcarrano it would change the current default behaviour. If we consider it a bug fix, that should be ok.

[tlabaj]

lgtm

[patternfly-build]

Your changes have been released in:

• eslint-plugin-patternfly-react@4.58.0
• @patternfly/react-catalog-view-extension@4.70.0
• @patternfly/react-charts@6.72.0
• @patternfly/react-code-editor@4.60.0
• @patternfly/react-console@4.70.0
• @patternfly/react-core@4.219.0
• @patternfly/react-docs@5.80.0
• @patternfly/react-icons@4.70.0
• @patternfly/react-inline-edit-extension@4.64.0
• demo-app-ts@4.179.0
• @patternfly/react-integration@4.181.0
• @patternfly/react-log-viewer@4.64.0
• @patternfly/react-styles@4.69.0
• @patternfly/react-table@4.88.0
• @patternfly/react-tokens@4.71.0
• @patternfly/react-topology@4.66.0
• @patternfly/react-virtualized-extension@4.66.0
• transformer-cjs-imports@4.57.0

Thanks for your contribution! 🎉