Tooltips and popovers often look correct in an isolated component story and fail in the page that actually uses them. The panel clips inside a container, covers its trigger, points at the wrong icon after scrolling, or jumps to an unreadable position near the viewport edge.
Pixelay lets teams compare Figma frames with live, staging, local, and authenticated webpages using overlay and other comparison modes. For floating interface elements, useful visual QA requires a controlled trigger, anchor, viewport, content fixture, and open state.
Distinguish the component behaviors
Agree on what is being tested. A tooltip usually provides brief supporting information and is not a good home for required actions. A popover may contain structured content, controls, or links and therefore needs more deliberate focus and dismissal behavior.
Document the trigger, opening inputs, delay, placement preference, fallback placements, collision padding, arrow behavior, width rules, focus expectations, dismissal rules, and responsive alternative. A screenshot of one ideal open state cannot specify all of that.
This workflow is narrower than a general modal and drawer QA workflow. Floating elements remain spatially tied to a trigger and must continuously adapt to clipping boundaries, scrolling, and available space.
Create deterministic placement fixtures
Build test pages or states with anchors in the center, each viewport edge, container corners, a scrollable panel, a transformed parent, a sticky header, and content behind an overlay. Include triggers near other controls and in repeated rows.
For content, test:
- a short label;
- the longest expected localized text;
- a heading, paragraph, and action;
- an unbroken token or URL;
- optional content missing;
- loading and failure states where supported;
- enlarged text and browser zoom.
Give each case a stable route or story so the same Figma frame can be compared with the same implementation state. If positioning changes every time data loads, a visual diff cannot provide reliable evidence.
Align the anchor before inspecting the panel
First compare the surrounding page and trigger with the floating element closed. Fix container width, scroll position, responsive breakpoint, and trigger geometry. Then open the element and compare panel size, offset, arrow alignment, shadow, radius, spacing, and typography.
Overlay differences are easier to interpret when the anchor already matches. If both trigger and panel are shifted, the bug may belong to the page layout. If the trigger matches but the panel does not, investigate the positioning system or component tokens.
Do not force the implementation to match a static top placement when there is insufficient space. The correct result may flip below or shift sideways. Figma should include those boundary outcomes so reviewers can distinguish intended collision handling from accidental drift.
Stress every boundary
Open the component near the top, right, bottom, and left edges at breakpoint boundaries. Check that it stays visible, retains sensible padding, and points clearly enough to the trigger after shifting or flipping.
Then scroll every relevant ancestor. Verify whether the element should remain anchored, close, or move with its trigger. Watch for clipping caused by overflow, stacking failures under headers or dialogs, and incorrect placement after page zoom.
Test within tables, cards, modals, sidebars, and horizontally scrolling regions. Portaled overlays can escape clipping but create different stacking and coordinate problems. Record the DOM and container context in every bug report; “popover is misaligned” is not enough to reproduce it.
Review interaction and focus separately
Pixel comparison cannot prove the component is operable. Test mouse, keyboard, touch, and screen reader behavior according to the component’s intended semantics.
For tooltips, verify that focus and hover can reveal the same essential information, the content remains available long enough to perceive, and the tooltip does not contain unreachable actions. For interactive popovers, verify initial focus, tab order, Escape behavior, outside-click behavior, return focus, and whether opening one closes another.
Check that the floating panel does not obscure the trigger or essential nearby content unnecessarily. On touch devices, hover-only behavior needs an intentional replacement. At small widths, a popover may need to become a sheet or another responsive pattern rather than shrinking beyond usability.
Separate token drift from positioning defects
Classify discrepancies before assigning them:
- page layout: the trigger or containing block is wrong;
- component styling: padding, typography, border, radius, or shadow differs;
- positioning: offset, flip, shift, or arrow calculation is wrong;
- content: the wrong copy or fixture is shown;
- interaction: open, close, focus, or scroll behavior differs;
- design gap: Figma does not define the encountered state.
Capture the route, viewport, zoom, scroll position, trigger, input method, content fixture, preferred and actual placement, and matching Figma frame. Pair visual evidence with a short recording when the defect occurs during scrolling or opening.
The visual bug report workflow provides a broader handoff format. Floating components particularly need the anchor and boundary conditions recorded.
Sign off the system, not one screenshot
Before release, cover all placement preferences, viewport edges, breakpoint transitions, scroll containers, overlays, short and long content, zoom, localized text, keyboard focus, touch behavior, dismissal, stacking, and reduced-motion behavior where animation is present.
Pixelay makes the spatial mismatch visible once the state is reproducible. That precision helps teams stop arguing about whether a popover “feels off” and identify whether the actual problem belongs to layout, tokens, collision logic, content, or an unspecified design state.
Read as Markdown Related resource index Site index for AI agents
Pro Bundle