<img> (src / data-src / data-lazy) and CSS background-image50 × 50 px, min area: 1,000 px²50–5,000 px per side0.1 – 10icon, favicon, sprite, logo, badge, emoji, avatar, button + .icorole="navigation", role="menu", or class/id matching nav|sidebar|rail|menu-bar|app-bardisplay:none, visibility:hidden, opacity:0<svg>, <object>, <canvas>, CSS mask-imageThese <img> tags are smaller than the 50×50px / 1,000px² minimum. Extension should NOT show the button.
These images are large enough to detect, but their URLs contain blocked keywords. Extension should skip them.
Alt text keywords only filter images with area < 10,000px². Large images with the same alt text should still be detected.
Images inside nav, sidebar, menu-bar, or role="navigation" containers are skipped regardless of size.
The extension skips display:none, visibility:hidden, and opacity:0. But partial opacity, transforms, z-index, and overflow clipping are NOT filtered.
Standard content images with clean URLs, no blocked keywords, well above size thresholds. Extension should always detect these.
Extension monitors data-src, data-lazy, and loading="lazy". These simulate common lazy-load patterns.
Extension extracts background-image from computed styles. These test whether that detection works on various container sizes.
These element types are not targeted by the extension at all. No <img> or background-image = invisible to the extension. Confirm the button does NOT appear.
The extension uses position:fixed for the button and viewport intersection checks. These test tricky positioning scenarios.
This is the core problem. The extension uses getBoundingClientRect() which reports the
element's layout box, not the visible clipped area. A 1200px image inside a 60px overflow:hidden
container still reports rect.width = 1200 → passes the 50px check → button appears on what
looks like a tiny icon. Similarly, object-fit, clip-path, and CSS scaling can cause mismatches
between what's visible and what the extension measures.