How to capture a sticky ISI in a full-page screenshot

Every pharma website with a branded product page carries Important Safety Information, and most of them present it twice: once in full, in the page flow near the bottom, and once as a sticky tray pinned to the bottom of the viewport that follows the visitor as they scroll. That tray is the thing that breaks a full-page screenshot.

This guide explains why, what a reviewer actually needs from the capture, how to do it by hand or by script, and the failure modes that catch teams out. It is written by RouteShot, which does this automatically, but the first two-thirds apply whichever way you capture.

Why the tray breaks the screenshot

A full-page screenshot is not one photograph. Whichever tool takes it, the page is taller than the viewport, so the capture is either the browser’s native full-page mode or a scroll-and-stitch: scroll, capture a viewport-sized segment, scroll again, compose the segments into one tall image.

The ISI tray is positioned fixed or sticky. It is a viewport feature: it stays at the bottom of the window no matter how far down the page you are. In a scroll-and-stitch, that means it is present in every segment, and the composed image shows it repeated as a band every viewport-height down the page, covering whatever content sat beneath it in each segment. Reviewers call this the ISI “baked into” the page, and it is the most common reason a capture gets sent back.

Browser-native full-page mode has its own problems on these sites. It silently clamps very tall pages, and pharma pages get very tall once accordions are expanded and the in-flow ISI is included. It also mis-composites pages whose scroll handlers change layout, which describes most pages with a sticky tray. The result is a screenshot that ends partway down or shows the wrong state, with no error.

Meanwhile the complete ISI is already in the document, in the page flow at the bottom, and any correct full-page capture already includes it. The tray in the full-page shot is redundant at best and destructive at worst.

What a reviewer actually needs

A page with an ISI needs more than one capture, and each one has a job.

1. Above-the-fold, tray visible. The page as a visitor first sees it, with the minified tray at the bottom of the viewport. This is the capture that shows the ISI is present on arrival, which is the point of the tray.
2. Full-page, tray hidden. The whole page, top to bottom, with the in-flow ISI complete at the bottom and no floating band anywhere. This is the capture that shows the ISI content in full and the page content unobstructed.
3. The expanded state. The tray opened by its control, as its own artifact, so the reviewer can see what a visitor sees when they expand it without leaving the page.
4. The collapsed state, if the tray is open at rest. Some sites load with the tray expanded and let the visitor collapse it. That is the other side of the same control, and it needs its own capture.

Two widths, desktop and mobile, for each of those. And a record of which page, which width, which state, on which date, because the first question in review is whether the ISI was captured correctly on the pages that matter most for legal.

Doing it by hand

This is workable for a few pages and unworkable for forty, but it is the ground truth for what a tool should do.

1. Load the page at the standard desktop width. Scroll to the bottom and back to the top so lazy-loaded images render, then wait a moment.
2. Take the above-the-fold capture with the tray showing.
3. Open the browser’s developer tools, find the tray element, and set it to display: none. Do not delete it. Some trays are re-shown by a scroll handler, so check it stays hidden after you scroll.
4. Take the full-page capture. If your extension produces a band anyway, it is using native full-page mode; switch to one that stitches.
5. Restore the tray, click its expand control, and capture the viewport with the tray open. On mobile the open tray can be taller than the screen, so one control per capture rather than everything open at once.
6. Repeat at the mobile width. Name each file with page, width and state, and log the date.

The problem is not any single step. It is that every step happens per page, per width, at every review milestone, and the record lives in filenames.

Doing it by script

Teams with a developer sometimes automate the manual steps with Playwright or Puppeteer. The things that matter, learned the hard way:

• Detect the tray by position, not just by name. Common markup is #isiPanel or a class containing isi, but some sites use a bare class="tray" and nothing else. Test for computed position: fixed or sticky on candidate elements, and fall back to the tray’s heading text.
• Mark the tray once, then hide by the mark. If your stitcher rewrites fixed elements to absolute mid-capture, a position test stops matching at exactly the moment the tray is about to be composited in. Tag it on first sight and hide the tag with display: none !important.
• Stitch, do not use native full-page. Force scroll-behavior: auto, wait for the scroll position to settle before each segment, and keep fixed headers in the first segment only.
• Verify expansion by measurement. Click the control, then measure the tray’s height. Grew means expanded. Shrank means it was open at rest and you just captured the collapsed side. Vanished with the page scrolled means the control was an anchor to the in-flow ISI, not an expander. Only the first of those is the expanded state.
• Budget for maintenance. The tray markup changes with the next site build, and the script silently captures nothing until someone notices.

How RouteShot does it

RouteShot treats the ISI as a first-class capture target rather than an obstacle. With “site has ISI” on for a project:

• The sticky tray is detected from common markup patterns and by position, with a text fallback for trays that carry no ISI token in their markup. A project can name the tray element explicitly for a site with unusual markup, and nothing is added to the page.
• Full-page captures are scroll-and-stitch, never native full-page. The tray is hidden in the full-page shot, and the in-flow ISI at the bottom is always included.
• The above-the-fold shot keeps the tray visible.
• Every control in the tray is tried from its resting state, and the outcome is measured: an expansion is captured as the expanded state, a tray that was open at rest yields a collapsed state, and a control that jumps to the full ISI is recorded as that rather than called a failed expansion.
• A run that has ISI enabled but finds no tray anywhere raises a flag rather than passing silently.

By default the expanded state is captured on the landing page and full-page captures on every page. A project can turn on above-the-fold and expanded-state captures for every page if the review needs them. For non-pharma sites, ISI handling is switched off and costs nothing.

Failure modes to check before you submit

Whichever way you capture, look for these before the set goes into routing.

• A band mid-page. The tray got into the full-page shot. Hide it and recapture.
• The page ends early. Native full-page mode clamped a tall page. Stitch instead.
• A tray that appears on scroll. Hidden at the top, revealed by a scroll handler. Check the full-page shot below the fold, not just the top.
• The ”+” was a link. The control scrolled to the full ISI instead of expanding the tray. You have a jump, not an expanded state.
• Open at rest. The site loads with the tray expanded. You need the collapsed state as well.
• Mobile overflow. The open tray is taller than a 375px viewport. Capture one control at a time.
• Missing images. Lazy-loaded images below the fold rendered as blanks. Scroll to the bottom and back before capturing.
• A sticky header repeated. Same mechanism as the tray, at the top. Keep it in the first segment only.

If those are clean at both widths and every state has a file with a name a reviewer can read, the set is ready. If you are doing this on more than a handful of pages, request access and we will run one of your live sites so you can compare the output with what you produce today.

Written by the RouteShot Editorial Team from primary sources, cited inline. How we write and review guides · Report an error