Re-anchors the fit tooltip onto the swapped workbench's real slot positions #77
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/fit-tip-reanchor-geometry"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes the returning fitting bug: changing a module's state (online, overheat) sent its tooltip to the top-left corner.
Root cause: a state change swaps the whole workbench for the fresh simulate fragment. The fresh slots' positions ride data-left / data-top (CSP forbids inline styles) until app.js's geometry pass applies them, and that pass runs from a MutationObserver, which fires after the swap handler finishes. The handler re-anchors the open tooltip synchronously, so it measured every fresh slot at the visual's top-left corner, where an unpositioned slot sits, and placed the tooltip there.
The fix applies the geometry pass to the fresh workbench inside the swap handler, before the re-anchor measures anything. app.js exposes the pass as EveSynapseContent.applyDataGeometry; the observer's later run over the same elements is idempotent.
Tests: a new case in fit.tip.test.js models the production timing (swapped slots at the corner until the pass runs) and pins the re-anchored tooltip to the slot's real position; it fails without the fit.js change and passes with it. The full fit.tip suite (13) and the loadout preview, phone views, swap and tabs suites all pass.