Sticky and Fixed Elements in Full-Page Captures: Detection, Suppression, and Verification

A header that looks correct in the browser can appear six times in a full-page screenshot. The page did not duplicate the header; the capture process observed the same viewport-attached element at six different scroll positions. The same effect can affect cookie banners, chat launchers, video controls, progress indicators, and “back to top” buttons.

This guide explains the distinction between document content and viewport-attached interface, then documents the current Screenshot PDF 0.0.13 strategy. It also shows how to verify the result without pretending that one selector can identify every floating component on the web.

Why repeated headers happen

Elements with CSS position: fixed are positioned relative to the viewport. Sticky elements behave like normal content until they reach a threshold, then remain attached while their container scrolls. MDN's position reference describes these layout behaviors.

A full-page tool that captures one viewport after another sees the element in every slice. When those slices are stitched using document coordinates, the repeated element becomes part of the image at each boundary. Converting fixed to absolute is tempting, but changing positioning can trigger reflow, alter responsive breakpoints, overlap content, or move the element into an unrelated location.

Screenshot PDF preserves layout

The extension records each candidate's original inline visibility value. It does not rewrite the element's positioning. After the first slice, candidates are hidden with an important visibility rule; their occupied layout and the dimensions of surrounding content remain stable. At the end, the original visibility is restored.

The first slice deliberately retains the header and other visible interface. This preserves the beginning of the page as the user saw it while avoiding repetitions later. If the header itself is irrelevant or contains private account information, dismiss or mask it before capture rather than assuming the extension should remove it.

How floating candidates are discovered

There is no universal sticky-header class. Screenshot PDF combines two approaches:

1. It examines likely semantic elements and class or ID patterns such as headers, navigation, footers, toolbars, and names containing fixed or sticky.
2. It samples a five-by-five grid of points across the visible viewport, inspects up to eight visual layers at each point, and walks several ancestors to find computed fixed or sticky positioning.

The visual sampling step catches CSS-module and runtime-generated interfaces whose class names reveal nothing. It also runs again during later slices because some sites create login prompts, advertisements, or application bars only after scrolling.

This is a bounded heuristic, not a proof. A tiny floating element outside the sampled points, a component inside a closed shadow root, or an overlay created during the instant of capture may escape detection. The result still requires inspection.

A five-step verification test

Use the public capture fixture, or construct a non-sensitive page with one sticky header and one fixed corner badge.

1. Record browser version, extension version, viewport, zoom, and theme.
2. Capture the page in full-page mode.
3. Confirm the header appears once at the beginning.
4. Inspect every seam for repeated headers, missing content, or a new blank band.
5. Return to the source tab and confirm its controls are visible again and the scroll position has returned to the top.

Step five matters. A visually correct output is not enough if the source page remains modified after an exception.

Distinguish duplication from overlap

A repeated header has the same pixels at regular viewport intervals. An overlap usually shows two different content regions occupying the same space, often because page height changed between captures. Late-loading images, expanding advertisements, font swaps, and animated accordions can move content after a slice has already been recorded.

If the pattern is identical and periodic, investigate fixed or sticky interface. If the pattern contains different content or irregular offsets, stabilize the page: wait for media, pause animation, close expanding panels, and capture smaller sections. Hiding a header will not fix a layout that is still changing height.

Consent and chat controls require judgment

Cookie consent controls may be part of the state you need to document. A support case about a consent banner should not automatically remove it. Conversely, a banner unrelated to the document may obscure content or repeat at every seam. Decide what the capture is intended to prove before dismissing anything.

Chat launchers can display names, message previews, or unread counts. Close them before capture when they are unrelated. If chat content is the subject, use a dedicated capture with appropriate redaction and do not rely on automatic floating-element suppression to preserve a conversation.

Known failure modes

• A sticky element nested in a transformed ancestor may behave differently from an ordinary page header.
• Shadow-DOM components may not be reachable by normal document selectors.
• A site can recreate an overlay after it has been hidden.
• An infinite feed may never expose a stable final endpoint.
• Virtualized lists can remove off-screen content regardless of floating-element handling.
• Cross-origin frames maintain their own document and layout context.

When a limitation matters, capture shorter overlapping sections, use the page's print view, or use an official export. Record the workaround rather than presenting the result as an untouched full-page state.

Acceptance criteria

A successful floating-element result has one intentional header, no repeated toolbars at seams, no content shifted into the hidden element's space, and a fully restored source page. Compare the top, middle, and bottom at actual size. This verification is more reliable than judging a compressed thumbnail.

Repeated headers are a layout problem with a testable mechanism. Preserve the first meaningful instance, suppress later viewport copies without reflow, restore the source page, and document anything the heuristic could not safely decide.