[EuiPopover] Change hasArrow, position and offset defaults

[mgadewoll]

Summary

Closes #9184

This PR updates EuiPopover by changing the default values of these props to change the visual output of the component:

• hasArrow
• position
• offset

prop	type	new default	old default
hasArrow	boolean	false	true
position	union	downLeft	downCenter
offset	number	hasArrow ? 0 : 4	4

Additionally, EuiInputPopover is updated by changing its offset.

prop	type	new default	old default
offset	number	2	0

EuiTourStep is updated to only set hasArrow on its underlying EuiPopover by default when decoration="beacon" and not decoration="none" (unless manually overridden).

Why are we making this change?

🎨 UI refresh: The changes are part of the effort to refresh and modernize the UI (#9183)

Screenshots #

EuiPopover

before	after

EuiInputPopover

before	after

EuiTourStep with decoration="none"

before	after

Impact to users

QA

🧪 Storybook:

• EuiPopover
• EuiInputPopover
• EuiTourStep

Checks:

• verify EuiPopover updates are correct and that manually set props apply as expected
  • it's rendered without arrow by default
  • its default position is downLeft
  • its default offset is 4 with hasArrow=false and 0 with hasArrow=0 (same as production)
• verify EuiInputPopover has a default offset of 2
• verify EuiTourStep with decoration="none" does not render an arrow by default (applying hasArrow will still override this)
• verify there is otherwise no unexpected regression between production and staging states

General checklist

• Browser QA
  • Checked in both light and dark modes
  • Checked in both MacOS and Windows high contrast modes
    • (emulate forced colors if you do not have access to a Windows machine.)
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Checked for accessibility including keyboard-only and screenreader modes
• Docs site QA
  • Added documentation
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
  • Checked Code Sandbox works for any docs examples
• Code quality checklist
  • Added or updated jest and cypress tests
  • Updated visual regression tests
• Release checklist
  • A changelog entry exists and is marked appropriately
  • If applicable, added the breaking change issue label (and filled out the breaking change checklist)
  • If the changes unblock an issue in a different repo, smoke tested carefully (see Testing EUI features in Kibana ahead of time)
• Designer checklist
  • If applicable, file an issue to update EUI's Figma library with any corresponding UI changes. (This is an internal repo, if you are external to Elastic, ask a maintainer to submit this request)

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e72009c
• Documentation website
• Storybook

History

• 💚 Build #1963 succeeded 6d513e7
• 💚 Build #1962 succeeded 5557349
• 💚 Build #1960 succeeded 0db0acd
• 💚 Build #1959 succeeded 1a0a2c9

cc @mgadewoll

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e72009c

cc @mgadewoll

[JoseLuisGJ]

LGTM @mgadewoll BTW the related Figma component was added to the new Borealis library and is using the same new defaults here

[mgadewoll]

LGTM @mgadewoll BTW the related Figma component was added to the new Borealis library and is using the same new defaults here

@JoseLuisGJ Awesome, thanks a lot for the update! 🎉

[JoseLuisGJ]

Not sure which version of EUI are we using in Storybook but I see this border in the union of the arrow and the Popover content in dark mode.

[mgadewoll]

Not sure which version of EUI are we using in Storybook but I see this border in the union of the arrow and the Popover content in dark mode.

@JoseLuisGJ I can see it on a Retina display in Chrome and only for the left aligned positions (leftUp, leftCenter, leftDown). That means it's most likely related to different sub-pixel calculations which browsers handle differently.

browser	retina	non-retina
Chrome
Safari
Firefox

If we try to change the position further inwards, then other displays look not aligned.

I think it's somewhat of an edge case.
It's only happening for left-aligned popovers because the position depends on the content width. If the width has sub-pixels, it'll be calculated differently (some round up, some down).
Depending on the content it looks fine or not. So the specific content "This is a popover" results in a width that results in exactly that arrow position that results in a visible line due to sub pixels. (also, if you zoom it's fine again)

Examples

looks fine

popover min width

same issue