From fd6df84e2a33b12c843b4bac24bfbc8fbfc4a5c2 Mon Sep 17 00:00:00 2001
From: amandaesmith3 <amanda.s@ionic.io>
Date: Thu, 15 Feb 2024 12:37:35 -0600
Subject: [PATCH] more comments

---
 core/src/components/popover/animations/ios.enter.ts | 7 ++++++-
 core/src/components/popover/animations/md.enter.ts  | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/core/src/components/popover/animations/ios.enter.ts b/core/src/components/popover/animations/ios.enter.ts
index ca12b8bc17..d3df71ab1e 100644
--- a/core/src/components/popover/animations/ios.enter.ts
+++ b/core/src/components/popover/animations/ios.enter.ts
@@ -152,6 +152,11 @@ export const iosEnterAnimation = (baseEl: HTMLElement, opts?: any): Animation =>
        * The left position is the same, but using x-axis values instead. We do this through
        * pure CSS to avoid needing to call window.getComputedStyle() to figure out the computed
        * safe area, which is very expensive and would introduce performance issues.
+       *
+       * The clamp() function is available in all browsers we support as of Ionic v7, except for
+       * Firefox. The function was introduced in Firefox 75, which is conveniently the new minimum
+       * supported version in Ionic v8. As such, we'll probably want to just push the fix to v8,
+       * if v8 isn't already out by the time we get to this.
        */
       contentEl.style.setProperty('top', `clamp(calc(var(--ion-safe-area-top, 0px) + var(--offset-y, 0px) + ${arrowHeight}px), calc(${top}px + var(--offset-y, 0px)), calc(100% - ${contentHeight + arrowHeight}px - var(--ion-safe-area-bottom) + var(--offset-y, 0px)))`);
       contentEl.style.setProperty('left', `clamp(calc(var(--ion-safe-area-left, 0px) + var(--offset-x, 0px)), calc(${left}px + var(--offset-x, 0px)), calc(100% - ${contentWidth}px - var(--ion-safe-area-right) + var(--offset-x, 0px)))`);
@@ -178,7 +183,7 @@ export const iosEnterAnimation = (baseEl: HTMLElement, opts?: any): Animation =>
            * The problem with this approach is that the popover content hits the max value
            * sooner than the arrow, due to being taller. If you present a popover low enough
            * on the screen to need safe area adjustment, but not so low that the popover flips
-           * to present above the trigger, the arrow will render inside the popover because
+           * to present above the trigger, the arrow will render overlapping the popover because
            * the content has been adjusted for safe area but the arrow has not.
            *
            * In theory, the most straightforward way of fixing this would be to calculate the
diff --git a/core/src/components/popover/animations/md.enter.ts b/core/src/components/popover/animations/md.enter.ts
index bdc7c9fbe8..870e23ca0e 100644
--- a/core/src/components/popover/animations/md.enter.ts
+++ b/core/src/components/popover/animations/md.enter.ts
@@ -79,7 +79,7 @@ export const mdEnterAnimation = (baseEl: HTMLElement, opts?: any): Animation =>
   wrapperAnimation.addElement(root.querySelector('.popover-wrapper')!).duration(150).fromTo('opacity', 0.01, 1);
 
   /**
-   * NOTE: See ios.enter.ts for details on what this is doing. For MD, this works perfectly.
+   * NOTE: See ios.enter.ts for details on what this is doing. For MD, this should work great.
    * Technically, the logic for whether to flip the direction of the opening animation doesn't
    * account for safe area, so there's a safe-area-margin-sized window where it flips in
    * the wrong direction. However, because the margin is usually pretty small, this is barely