fix: better relying on applied paint state for computing padding on a…

…nchor elements

.changeset/thick-news-refuse.md

@@ -0,0 +1,7 @@
+---
+'@inventage-web-components/portal-navigation': patch
+---
+
+Instead of relying on two nested `requestAnimationFrame` callbacks to detect when style and layout information have been applied (for computing the `anchor` padding in `sticky` mode), we instead now use `requestAnimationFrame` in combination with `setTimeout`.
+
+This should hopefully give us a more reliable hook into the point in time where the style and layout information have been calculated and the paint has occurred.

packages/portal-navigation/src/PortalNavigation.ts

@@ -478,11 +478,12 @@ export class PortalNavigation extends LitElement {
       this.dispatchEvent(new CustomEvent(NavigationEvents.breakpointChanged, { detail: this.isMobileBreakpoint, composed: true, bubbles: true }));
     }
 
-    // Wait two paint cycles until CSS styles have been applied…
+    // This code will be run ASAP after Style and Layout information have been calculated and the paint has occurred.
+    // @see https://firefox-source-docs.mozilla.org/performance/bestpractices.html
     requestAnimationFrame(() => {
-      requestAnimationFrame(() => {
+      setTimeout(() => {
         this.updateAnchorPaddingWhenStickyInternal();
-      });
+      }, 0);
     });
   }