How to Handle Google Vignette Ads with Robot Framework

Imagine your perfect test script failing because a massive, full screen Google Vignette ad blocked the page. If you automate public sites, such as Automation Exercise, you know the pain of ads you can’t disable breaking your tests. Fortunately, you can outsmart them. Today, I’ll show you two practical methods within Robot Framework to handle these annoying ads and get back to green results.

Method 1: The UI Approach (Context Switching)

This method handles the ad exactly like a real human would: it waits for the ad to appear, finds the Close button, and clicks it.

When the ad pops up, it loads inside an iframe (an HTML document embedded inside the main website). Your Selenium webdriver cannot see the “Close” button because it is looking at the main website, not inside the iframe. To fix this, we must tell Robot Framework to “switch focus” into the ad’s iframe, click the button, and then switch back to the main page. Let’s take a look to see how we can implement this inside the code

*** Settings ***
Library    SeleniumLibrary

*** Variables ***
# Timeouts
${VIGNETTE_TIMEOUT}    5s
${DISMISS_TIMEOUT}     3s

# Locators
${VIGNETTE_IFRAME}     css=iframe[name^="google_ads_iframe"]
${DISMISS_BUTTON}      id=dismiss-button

*** Keywords ***
Check And Dismiss Google Vignette
    [Documentation]    Checks the URL for the Google Vignette flag and dismisses the ad if present.
    ${current_url}=    Get Location
    ${is_vignette}=    Run Keyword And Return Status    Should Contain    ${current_url}    #google_vignette
    
    IF    ${is_vignette}
        Close Vignette Overlay
    END

Close Vignette Overlay
    [Documentation]    Switches into the Google ad iframe and clicks the close button.
    Wait Until Element Is Visible    ${VIGNETTE_IFRAME}    timeout=${VIGNETTE_TIMEOUT}
    Select Frame    ${VIGNETTE_IFRAME}
    
    ${btn_found}=    Run Keyword And Return Status    Wait Until Element Is Visible    ${DISMISS_BUTTON}    timeout=${DISMISS_TIMEOUT}
    IF    ${btn_found}
        Click Element    ${DISMISS_BUTTON}
    END
    
    Unselect Frame

However, there are a couple of drawbacks to keep in mind with this method. It is generally slower because waiting for the ad to fully render adds precious seconds to your test execution, which really adds up across a large test suite. Additionally, it can be quite flaky since Google frequently changes the HTML IDs of their close buttons; if that ID changes suddenly, your test will fail until you track down the new one and update your code.

If you want a cleaner and much faster way, we can use an approach I call “loopback blackholing.” This stops the ad from loading completely. We do this using ChromeOptions to tell the browser to reroute known Google ad domains directly to 127.0.0.1 (your local computer). This acts like a black hole for the ad requests, preventing them from ever reaching the server.

When you use the code below, your browser is instructed to intercept any network requests destined for the list of ad domains and force them to load from your own machine instead. Since your machine does not have the ad content, the request simply fails quickly and silently, and the ad can never block your screen. It is an extremely efficient way to manage external dependencies.

*** Variables ***
${AD_SINKHOLE_RULES}    MAP googleads.g.doubleclick.net 127.0.0.1, MAP pagead2.googlesyndication.com 127.0.0.1, MAP tpc.googlesyndication.com 127.0.0.1, MAP www.googletagservices.com 127.0.0.1

*** Keywords ***
Open Browser With Network Adblock
    [Arguments]    ${url}
    
    ${options}=    Evaluate  sys.modules['selenium.webdriver'].ChromeOptions() sys, selenium.webdriver
    Call Method    ${options} add_argument   --host-resolver-rules\="${AD_SINKHOLE_RULES}"
    Call Method    ${options}    add_argument   --ignore-certificate-errors
    
    Create Webdriver    Chrome    options=${options}
    Go To    ${url}
    Maximize Browser Window

However, this approach does come with a couple of catches. First, you lose out on testing the “true” user experience. Because the ad never actually loads, your test isn’t reflecting exactly what a real person will see when they visit the page. On top of that, it requires a little bit of ongoing maintenance. Google uses a lot of different domains to serve these ads, so make sure to keep an eye out and update the blocklist as new domains pop up over time.

In conclusion, both of these strategies are excellent additions to your automation toolkit, but they excel in different situations. Choose the Network approach (Method 2) for large test suites that require maximum speed and stability or stick with the UI approach (Method 1) when you specifically need to verify the true user experience and see how the system handles those annoying pop-ups.

Of course, these two methods are not the only ways to defeat Google Vignette ads! Are there any other creative tricks or alternative approaches you use to bypass them in your framework? Please feel free to share your best solutions in the comments below!