Hey Google … Why Does My Extension’s Hidden Message Appear in Google Search Results?

So here’s how the problem started.

For the past few years, I’ve been working (on and off, but mostly off) on the UI overlay for Ultrawidify, for various reasons ranging from “some people asked for it” to “they have a point, because extension buttons in the extension toolbar aren’t accessible in full screen, so adding in-player UI would be nice.” Also, personally, I get a neat large UI for debugging purposes.

The problem with UI is that Ultrawidify isn’t only limited to Youtube. It can also run on other sites (although, as of 6.2.4, users need to manually enable Ultrawidify for sites other than Youtube and Twitch), and every site implements its player UI in their own special way. Because of this, inserting UI into the website’s video player is not feasible. The only feasible solution is to create an overlay.

This doesn’t solve all the problems. If you insert new elements into a webpage, then page’s CSS can affect the look of your UI elements (and vice versa). We need a way to isolate my UI from the webpage it’s displayed on. Fortunately, we have the right tool for the job:

Transparent iframes

Iframes are a neat thing, because the webpage is completely unaware about what’s inside the iframe. Similarly, page displayed within the iframe has no idea on the rest of the webpage. This is neat, because we avoid cross-pollination of element styles.

But iframes also have some limitations. First, webpage displayed inside of an iframe cannot display elements outside of the iframe boundaries — this means that if we want our overlay to work correctly, the iframe needs to cover the entire video player.

And secondly … transparent iframes aren’t always transparent.

Websites may specify color-scheme property. This property tells the browser whether the website uses “dark mode” or “light mode”, and if color scheme of iframe doesn’t match the scheme of the webpage it’s on, the browser automatically applies background color to your iframe. Yes, even if your iframe is supposedly transparent.

So I implemented a way to detect what color-scheme a website is used, and adjusted color-scheme of the UI overlay. This worked until it didn’t. Disabling the color-scheme seemed to fix the issue on sites that I could verify, and didn’t introduce any new issues when I went to youtube, and then twitch, then I also got myself two months of netflix from the donation pool, and whatever free streaming sites people threw at me. Problem solved, right? Not really, because this appeared to solve the issue for some and introduced new issues for some others.

This means that we’re in a bit of a bind, because there’s two options that I know of, and they both break things for two different sets of people according to the precious few reports that aren’t whining with no useful information. With people doing nothing other than whining and in some cases possibly lying, it was time to consider workarounds that were a bit more “out there.”

So why can’t we just screenshot the entire tab?

In theory, Google Chrome offers an API that extensions can use in order to get a screenshot of the current tab. We could use that API in order to screenshot the page, and then check that screenshot in order to see whether our iframe is transparent or not, and then automatically apply the correct fix based on results.

The idea was to add few small (1×4 pixels) dark markers in the corners and along the edges of the player, placed under the iframe. Since I know the position of those black markers, I could then check the correct positions on the screenshot for the presence of said markers. If at least one of the markers is correctly detected, that means everything is fine. However, if none of the markers is detected correctly, that means we need to change our color-scheme detection strategy. I also added a fun, but invisible easter egg.

So I went to work. This is the code for the markers.

<div style="position: absolute; ${anchorStyle} ${parentMainDimension}: 4px; ${parentCrossDimension}: 1px; pointer-events: none;">
  <div style="position: relative; width: 100%; height: 100%">
    <div style="position: absolute; ${mainAxis}: 0px; ${crossAxis}: 0px; width: 1px; height: 1px; background-color: #000102"></div>
    <div style="position: absolute; ${mainAxis}: 1px; ${crossAxis}: 0px; width: 1px; height: 1px; background-color: #030405"></div>
    <div style="position: absolute; ${mainAxis}: 2px; ${crossAxis}: 0px; width: 1px; height: 1px; background-color: #050403"></div>
    <div style="position: absolute; ${mainAxis}: 3px; ${crossAxis}: 0px; width: 1px; height: 1px; background-color: #020100"></div>
  </div>
  <div style="top: 5px; left: 5px; opacity: 0">
    This marker is Chrome Shitiness Mitigation mechanism for Ultrawidify. It turns out that as of 2025-01, Chrome does not correctly respect
    allowTransparency property on certain iframes, and will force white or black background across the entire element. It is unclear what's
    causing the issue — so far, it seems to appear randomly.
  </div>
</div>

When extension detected a video, it injected this code into the webpage. And while the “Chrome Shittiness Mitigation” message was (supposed to be) invisible for humans, it was still there on the page. However, since that message is inserted by my addon, there should be absolutely no reason this message should ever show in Google search res—

… wait what? And mind, it’s not just these three.

So how does that happen? Currently, there’s about two options that come to mind:

• Google is crawling websites with headless chrome, with each of those headless chrome instances having a random assortment of addons installed along with them
• Google is getting some of its crawling data from the websites users of Google Chrome visit

And both options come with some rather fun implications. Think that I might be able to pull a fun social experiment some time in the future.

Oh, excuse me, you’re here to learn the reason why transparent iframes weren’t always transparent?

The mystery of white “transparent” iframes, solved

Long story short:

• There are different two ways¹that I am aware of⁰ that a webpage can inform the browser that it’s using light or dark color scheme.
• If webpage declares its color scheme by setting appropriate <meta> tag in <head> of the HTML document, then my UI also needs to contain the same tag in the head of the document.
• However, if the webpage does not include <meta name="color-scheme"> tag and instead defines color scheme in style attribute on the <html> tag, then you (in addition to the previous line) also need to put a matching color-scheme property in the style attribute of the <iframe> tag. Which is why color scheme detection appeared to not work properly on some sites, and I wasn’t quite aware that you could put color-scheme: dark in the style attribute at the time.
• The reason why some people experienced this issue on Youtube while I didn’t? Youtube was doing their A/B testing thing, and some people ended up with a different version of youtube than me.

Chrome got blamed because let’s be brutally honest: when some people say “this is broken” and post receipts in form of screenshots, your first two thoughts are going to be “conflict with another addon” and “this must be a hardware-related Chrome bug.” The first one can be ruled out really fast even if the issue is reported by someone who isn’t very knowledgeable about technical aspects of how browsers work, as long as they’re slightly cooperative. And after what happened in 2022 and 2023, blaming hardware and/or Chrome for something that at least on the surface looks like a bug in a niche feature is completely reasonable. After all, we’ve been there.

If you wonder what the last two sentences are talking about: In january 2022, Chrome broke video rendering when DX11 was used for hardware acceleration. The bug remained unfixed for over 9 months, but by the end of the year the bug was fixed…

… only for Google to break Chrome’s video rendering even worse in 2023 for at least 6 months, but possibly longer than that.