fix: Popover is positioned incorrectly when the layout changes

[connorlanigan]

Description

When an Annotation Popover is open, and the user interacts with the page so that the layout changes (e.g. toggling the side navigation panel), the Popover needs to update its position. With the existing heuristic, the Popover recalculates whenever the user clicks on the page (or interacts with a button using the keyboard), but the current logic assumes that any layout update then happens in a single frame. In the case of the navigation panel opening, it slides in with an animation, so the Popover only adapts to the first frame.

With this change, the Popover continuously updates its position for one second after the user interacts with the page. This should give enough time for any layout-related animations to finish, and it smoothly updates the Popover's position while its trigger moves. Since we're using requestIdleCallback, the browser will only execute these updates if the CPU is otherwise idle.

Related links, issue #, if available:

• AWSUI-60630

How has this been tested?

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[orangevolon]

Wondering if we could find a way to have a unit test for the 1000ms part of the logic.

[orangevolon]

Not sure if having an extra micro-task here is necessary. It took me some time to understand what's happening.

The way I read this is that: we create a micro-task, wait for a free cycle and then resolve the promise. This means the calculation doesn't happen in the cpu's free time, we just wait for a free CPU time to run the next cycle.

A simpler approach IMO would be simply having animation pattern:

function updatePosition() {
  if (controller.signal.aborted) return;
  if (performance.now() >= targetTime) return;
  
  updatePositionHandler();
  requestIdleCallback(updatePosition);
}

requestIdleCallback(updatePosition);

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.50%. Comparing base (4e31a2f) to head (7561daa).
Report is 47 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3427      +/-   ##
==========================================
- Coverage   96.51%   96.50%   -0.02%     
==========================================
  Files         806      804       -2     
  Lines       23028    23143     +115     
  Branches     7550     8013     +463     
==========================================
+ Hits        22226    22333     +107     
+ Misses        795      756      -39     
- Partials        7       54      +47     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[orangevolon]

wouldn't it be better to fallback to requestAnimationFrame rather than setTimeout?

[connorlanigan]

The position update does not necessarily need to be a smooth animation at the full refresh rate that the browser can do, it just shouldn't lag behind too much. So by using setTimeout, we get a reasonably good-looking behaviour without demanding too much performance from a potentially non-idle CPU.