Components: Allow style prop on Popover

[talldan]

What?

In #64321 I have a use case for using the style prop on the Popover component (see 'Why?').

I discovered that you can use the style prop, but doing so clears the style properties set by floating-ui that position the popover because of the way contentProps.style (contentProps collects the 'rest' of the component's attributes) overrides animationProps.style when the attributes are spread onto the component:

gutenberg/packages/components/src/popover/index.tsx

Lines 401 to 402 in e076070

	{ ...animationProps }
	{ ...contentProps }

In this PR I'm making the style prop work correctly.

How?

Spreads the style prop into the animationProps.style property, giving it lower precedence than other 'built-in' styles so that it isn't possible to break the popover's innate positioning.

Why?

#64321 renders a popover inside the editor canvas iframe and requires overriding margin (which is added by the block layout system) and zIndex (one of the popover's own styles). Due to the popover being inside the iframe, regular scss styles can't be used (they're not loaded in the iframe), so inline styles seem to be the obvious option.

There are possible alternatives:

• Add a prop that removes zIndex from the iframe (e.g. noZIndex), or allows setting a custom z index. The margin will still be overriden, but I can solve that by wrapping the popover in a div that has style={{margin:0}} specified. I'm not sure this solution is better than the one in this PR though, it adds an extra prop that's of limited use.
• Render a style sheet within the canvas iframe. I'm reluctant when it comes to this option as it adds much more complexity compared to using an inline style, which is simple and has no specificity issues.

Testing Instructions

A couple of unit tests have been added. I wasn't sure about adding a story for this - I thought it might be best to leave this prop undocumented just like the other html attributes that can be added via ...contentProps.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[mirka]

Makes sense, and the tests look great! Thanks 🚀

[mirka]

Technically we don't have to list this type explicitly, because it's already included as a div prop via WordPressComponentProps, and excluded from the MotionProps omitting.

And I guess this comment can be a bit misleading:

  // To avoid overlaps between the standard HTML attributes and the props
  // expected by `framer-motion`, omit all framer motion props from popover
  // props (except for `animate`, `children`, and `style`, which are
  // re-defined in `PopoverProps`).

Maybe "except for animate and children which are re-defined in PopoverProps, and style which is merged safely"?

[talldan]

Sounds good - done in c811da6. Thanks for the quick review!

[github-actions]

Flaky tests detected in c811da6.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10397832171
📝 Reported issues:

• [Flaky Test] image inserted via link should appear in the frontend published post content #52030 in /test/e2e/specs/editor/blocks/image.spec.js