Codex needs a comprehensive solution for handling the positioning and behavior of various floating elements – drop-down menus, tooltips, dialogs, etc. We need to ensure that these elements demonstrate the correct behavior in a variety of circumstances (inside multiple scrolling parents, inside dialogs, in RTL contexts, etc).
Re-using the OOUI solutions verbatim is not really feasible for Codex – OOUI is heavily reliant on jQuery (which Codex does not use) and the browser landscape has also changed considerably in the last few years (we now can safely rely on new APIs like intersection and resize observers, etc). At the same time, re-writing a complete solution entirely from scratch would take a considerable amount of time and effort, significantly delaying the production-readiness of Codex.
After some investigation (see T345116), we (the DST engineers) feel like the best path forward is to leverage the FloatingUI library and avoid re-inventing the wheel ourselves. FloatingUI is the successor to Popper.js, which was incorporated into Bootstrap to solve similar problems. The new library is similarly intended for this kind of low-level, embedded-inside-another-UI-library usage, while making use of modern browser capabilities and working well with frameworks like React and Vue. Additionally, FloatingUI's API includes a concept of "middleware" (chainable plugins basically) which we could rely on if we need to customize the library's behavior (for example, to provide specific RTL support).
With all of that being said, adding a new runtime dependency to Codex is not something we wish to undertake lightly. We need to do our due diligence in terms of security review, and we should take measures to minimize any potential breakage for Codex users due to upstream changes (pinning the library to a specific version or even vendoring it into our source code for example).
There will also be some necessary work required to integrate FloatingUI into Codex in the best way.