New Google AdSense ad intent anchors aren’t excluded

Hey,

our feature to exclude elements from screenshots uses the following CSS:

${hideSelectors} {
    visibility: hidden !important;
}

Unfortunately, the new Google Ad intent anchors use the following inline CSS on the ad element:

visibility: initial !important;

This inline CSS declaration has extremely high specificity and cannot be overwritten with other CSS selectors. That’s why the element still shows in the screenshot.

As a solution, you can try changing the element’s CSS declaration using JavaScript to reduce its specificity.

Best
Steffen

Thanks @steffenbew.

I actually don’t see any visibility declaration in the element.

See screenshot:

https://1drv.ms/i/s!AhEX_VIY1-zfhbk7ORNSNx_Y2Ly0pQ?e=YDVkPc

Am I missing something?

Thanks again.

It seems like the CSS is only present initially and then removed automatically by Google. That’s why it doesn’t show up in your inspector. However, there must have been a race condition with our script injecting the exclude CSS and clicking away the cookie banner, preventing the CSS to be removed.

We just implemented a little timeout hack into the screenshotter which resolved this issue on the specific website in our local tests. Please let us know if it works for you as well!

Thank you, @steffenbew! I will keep you updated.

@steffenbew, unfortunately the issue persists.

It seems the timing of the ads is changing. That would also make it difficult to solve the issue with JavaScript.

Maybe an option to use display: none !important can be introduced?

Another option, I although I don’t if possible, is to somehow use an ad blocker (or domain filters).

I assume this issue can occur with more ad formats and providers. In essence, ads are dynamic, so it might make sense to ignore them altogether for VRTs.

Oh bummer :/ Thanks for your feedback.

I like the idea of implementing an ad blocker! We’ll investigate the possibilities and will continue to look into your specific issue.

Thanks, @steffenbew.

Looking forward to updates.

Hi, @steffenbew.

I was wondering if you had made any progress or made any plans.

In the meantime, I’m dismissing a couple of false positives daily. Chances are growing that I will miss a true regression while I do so.

That got me thinking of a possible feature: the ability to jump to the next/previous difference within the screenshot alert, as you have in file diff tools. This can lower the chances of missing a difference when there are multiple differences. It might be more complicated to implement with images rather than text, but I thought to mention it.

A screenshot from NetBeans IDE history tool for illustration:

Screenshot 2024-06-03 184900.png

Let me know if the suggestion is clear enough.

Thanks again for a great tool.

Hey @asafm7, thanks for your patience and following up. We’ve spent quite some time looking more deeply into this issue.

When we developed and tested the fix, it seemed that Google removed their inline CSS after initialisation. That’s why you couldn’t find the CSS in your developer tools on May 15th. That was good for us, because it allowed our CSS to take effect, once we fixed a race condition.

Unfortunately, Google seems to have changed their script. Now, they always add a huge pile of inline !important CSS on each of their ads elements. This is overpowering every other CSS selector and leaving no sensible way to influence the display with CSS only.

We also considered clicking away the element with our plugin’s click selector, but that won’t work because the ad only comes in after scrolling the page beyond a certain threshold. Additionally, our click selector fires at the beginning of the page load, to click away cookie banners and allow for additional content or styles to be loaded as a result. That’s why we can’t simply delay the execution logic.

There are other ways to work around this issue – like Ad blockers, resource blockers, JavaScript injection, etc. – and we’re certainly considering them, but they’re all features that need thorough planning, no quick fixes.

However, it should be possible for you to exclude the ads script execution only for requests coming from our screenshot service IP. It seems that plugins like Ad Inserter and Advanced Ads provide such IP exclusion settings. That said, you’ll likely have to fine tune it to work with your site cache.

The feature suggestion to jump to the next/previous difference within the screenshot alert is great! We’ve recently discussed such feature on a concept level already. Implementing this in an image context does present some complexity, but it’s definitely something we are eager to explore further.

Again, thanks for the feedback and the encouragement. We’re always looking to improve VRTs based on real-world use cases like yours.

Thanks, @bleechberlin.

I’m using the official Google Site Kit plugin, which doesn’t have an IP exclusion feature.

I will give custom coding a try, although that, as you said, caching makes it a bit complicated.

Is there maybe an identifying User-Agent to exclude instead of IP?

Thanks again.

@asafm7 We currently use the standard user agent from the headless Chromium we’re running. While it could be convenient to add something to that user agent for identification purposes, we’re cautious about introducing a custom user agent at this stage.

Some firewalls are designed to block unknown or suspicious user agents, and without thorough research and testing, there’s a risk of encountering issues.

Thanks, @steffenbew.

Yes, I understand. It makes sense.

Looking forward to future solutions you’ll come up with.

Thanks again.