steffenbew

@grex22 We tested various approaches to prevent browsers and password managers from autocompleting the inputs (see PR: Add autocomplete control and multiple-email support to settings fields), but it didn’t reliably work. Sometimes, browsers still choose to ignore the markup instructions when they assume a user/password combination.

That’s why we decided to change the license key field to a text input. This appears to effectively prevent browser autocomplete. The saved license key is masked with XXX–XXX…

The change is now live in VRTs v2.0.7.

Thanks again for bringing this to our attention!

Hi Tim,

Thanks for getting in touch about this!

Before taking the screenshot, the screenshotter scrolls down the entire page, scrolls up again, and then captures a full-page screenshot. If sections only become visible when they are currently in the viewport (e.g. fade-in / intersection-observer animations), they can still end up hidden in the final screenshot.

VRTs exposes itself via the user agent string during screenshotting, so you can detect that and adjust rendering specifically for tests. The user agent contains the prefix: VRTs/<version>

You can check for that in JavaScript, for example:

if (navigator.userAgent.includes('VRTs')) {
    // Disable animations or reveal hidden sections for visual testing
}

This allows you to bypass scroll-triggered animations, IntersectionObserver logic, or other viewport-dependent effects during tests while keeping the normal behavior for real visitors. 

You can find the details in the docs here: https://vrts.app/docs/#user-agent

I hope this helps! Let me know if you need any further support with this.

Best
Steffen

Thanks for your detailed report! And sorry for the late response. It took us a while analysing the page and coming up with next steps.

The alert you’re seeing appears to come from layout shifts that happen after the initial load. The radio button group and CAPTCHA area at the bottom both resize slightly over time, and that creates pixel differences from one test to the next. Because the page is actually rendering differently in some of the tests, the alert keeps coming back even when flagged as a false positive. Fixing those layout shifts on the site side should solve the repeated alert.

About hidden elements: You’re absolutely right. Using visibility: hidden preserves layout space, so if the element changes internal size, it can still trigger differences. That’s why it doesn’t help with layout-shift style issues. We’re looking into offering more control here. We do not offer display: none for now, as removing elements from the layout may result in unexpected results.

Regarding false positives: currently, the feature only suppresses alerts when screenshot comparisons are a pixel-perfect match. Any other difference will still trigger an alert. That’s why it doesn’t help with more dynamic layout changes.

Based on your feedback, we started working on an AI-assisted guidance for configuring hide selectors and reducing noise in test results. It’s early, but we’re excited about where it’s heading.

Let us know if we can help identify the shifting elements more precisely. We’re happy to support you in stabilizing that page.

Hey there, I’m sorry to hear that. Please send a mail with the URL of the website to [email protected] so we can look into this specifically.

Hey @asafm7, did reinstalling the plugin work for you?

Thanks for reporting! This was fixed in v2.0.1.

Hey @asafm7, we need some more time to investigate this. Thanks for your patience!

@asafm7 fyi, we have added IPv6 and just added the IPs to our docs.