Google Meet displays a warning banner

[ldoron]

When I am in a Google Meet meeting in Chrome, Meet often displays a warning banner saying "You have extensions installed that may affect the quality of your call" (with a link to https://support.google.com/meet/answer/10550593?hl=en#meet_extension). I narrowed it down to OptMeowt -- when I Disable it (using the "pause button" icon) and reload the Meet tab, the warning goes away. However, if I try to just set each domain switch to "Do Not Sell Disabled" (that is, for google.com and all 3rd Party Domains shown) and reload, the warning still appears.

I haven't actually noticed any quality difference either way, but the banner sure is intrusive, and every time I have some other Meet problem -- not infrequent, unfortunately -- I feel like I have to click "Pause" and try again (though it hasn't made a difference). OptMeowt isn't actually a Meet extension, but I assume it must be doing something to trigger Meet's warning. It would be nice to eliminate the banner and the accompanying FUD.

Interestingly, as I was just testing this right now, after playing with turning the domain switches off -- which gets me logged out by Google (another issue, or expected?) -- then on, and logging in to Google again, I didn't see the banner. However, when I deleted my cookies a.k.a. "site data" (chrome://settings/content/all) from "meet.google.com" and reloaded the Meet tab, and then started a new instant meeting (had to allow mic and camera again), the banner was back.

[Jocelyn0830]

I was able to replicate the exact issue on my end. I have not found an easy fix but will look more into it.

[SebastianZimmeck]

Sounds good! Let's document here the different options we tried.

Any ideas so far, @Jocelyn0830?

[OliverWang13]

This is due to our scripting permission in our manifest. We can't remove this as it would remove our ability to set the DOM signal. I will look into some other extensions and see if they have done anything to deal with it.

[SebastianZimmeck]

@OliverWang13 and @Mattm27 will further look into this. In particular:

1. Is this just a Chrome issue? If yes, it is may be an mv3 issue (Switch to mv3 #175)
2. What happens when the scripting permission is not used? Are we still seeing that banner?
3. Are there other extensions that do/do not have this problem? What do they do?

[OliverWang13]

1. I just tried this on Firefox and there is no warning banner, supporting the theory that this is an MV3 issue.
2. As discovered earlier, when the scripting permission is not used, the banner goes away

Point 3 still requires more investigation.

[OliverWang13]

The extension Chrome Booster has the scripting permission but does not trigger the banner. I will look into how they are using their scripting permission.

[OliverWang13]

I've tried to implement some other methods of using the Scripting method, but they are not working for our purposes. I will look around a little more to see if I can find another open-source extension that has the scripting permission and other similarities to OptMeowt. However, I think this issue is not something that we can resolve and I will add it to the known bugs and quirks shortly.

[SebastianZimmeck]

However, I think this issue is not something that we can resolve and I will add it to the known bugs and quirks shortly.

OK, if you make that call, it would be helpful if you write more details here what the concrete problem is and what you have tried. Then, let's reference this issue in the new known bugs and quirks entry.

[OliverWang13]

Through a process of trial and error, I have found that this message is caused by our method of setting the DOM signal.

Using the scripting permission, we use dynamic content scripts to inject a static script into each page. This is where the issue arises. Specifically, the warning error does not pop up when line 34 in registration/gpc-dom.js is commented out. However, this also stops the DOM signal from being sent. Our method, as based on this stack overflow thread, injects a static file into the page, which is causing the error.

So while the warning message disappears when the scripting permission is removed, it is because of this file that is running using chrome.scripting.registerContentScripts.

I spent some time trying to change our method by using chrome.scripting.executeScript instead (like the BrowserBoost extension), but was not able to get it working. BrowserBoost uses the scripting permission and does not get the warning banner, but is not similar enough in function to our extension to provide valuable input for a workaround.

chrome.scripting.executeScript does not work because our content script does not have the correct scope to use it functionally, which is an issue we have faced previously in issue #259. In that issue, Kuba found that our current method is the only possible way to inject the DOM signal with a content script in the correct scope. Due to this, and the timing issue also outlined in #259, I think that we are currently using the best method.

[OliverWang13]

This has been documented and I will close it.