fix(popover): popover positions correctly on all frameworks

[sean-perkins]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Some docs updates need to be made in the ionic-docs repo, in a separate PR. See the contributing guide for details.
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

In framework implementations, the popover will incorrectly position when using an alignment property such as top or bottom. The delay in timing between when the popover contents are mounted in the DOM vs. when the transition starts is too low, resulting in the popover content's bounding box height evaluating to 0 and the popover positioning incorrectly.

Issue URL: #25337

What is the new behavior?

• React and Vue framework implementations use the new ionMount internal event when the popover is presented instead of willPresent. This allows the framework to mount the popover content earlier in the lifecycle of an overlay being presented.
• Uses two request animation frame loops to provide enough time for the framework to mount the popover contents. In Angular/React a single request animation frame appears to be enough time, but for Vue, two is required. Opted for two to be consistent.

Does this introduce a breaking change?

• Yes
• No

Other information

Dev-build: 6.3.8-dev.11668643678.159ccab8

[liamdebeasi]

Why do we need to wait 2 frames just in Ionic Vue?

[sean-perkins]

Short answer, I'm not sure. I tested with a single request animation frame delay and compared against each and only Vue did not render the inner contents in time for the transition. Bumping to two consistently rendered correctly. I'm not familiar to the internals of how Vue handles rendering.

My intention with this bug fix is looking at a target for a patch release, but realizing we should be able to rip most/all of this away in a minor or major release, if we change either or both:

1. The animation library to support asynchronous behavior.
2. Add support to overlays to accurately track when content is mounted before running the transition.

[liamdebeasi]

I'm fine with the changes since they resolve some critical popover functionality. Can we add a tech debt ticket to research alternative implementations that do not rely on dual rafs?

[sean-perkins]

Created FW-2875 to track, with additional detail as to what the problem we need to solve for is.