Mailto links handled by Gmail fail with ERR_TOO_MANY_REDIRECTS

[ghostwords]

If you set up Gmail to handle mailto links in Chrome, clicking mailto links in Chrome with Privacy Badger installed will probably produce the following error page:

This page isn’t working
mail.google.com redirected you too many times.

Try deleting your cookies.
ERR_TOO_MANY_REDIRECTS

One workaround is to re-navigate to the URL you are already on. To do so, click on the address bar and press Enter.

A more permanent workaround is to set the toggle for mail.google.com to the rightmost, green ("fully allow") position. To do so, open Privacy Badger's options page, select the Tracking Domains tab, search for mail.google.com, and set the toggle to green.

Clicking the Reload button does not help.

[ghostwords]

At first glance, the problem is that our "remove cookies" DNR rule for mail.google.com, despite being scoped to domainType: 'thirdParty', is applied to mail.google.com requests in a new, mail.google.com browser tab.

This seems to be happening because these requests are technically initiated by the page you clicked the mailto link on. This then appears to be another argument for excludedTopFrameDomains (w3c/webextensions#762).

It also seems like "domainType": "thirdParty" is buggy / does not work the way one would reasonably expect it to work.

[ghostwords]

Here is what the relevant DNR rule looks like (minus a million google.com country code domains in excludedInitiatorDomains):

{
    "action": {
        "requestHeaders": [
            { "header": "cookie", "operation": "remove" }
        ],
        "responseHeaders": [
            { "header": "set-cookie", "operation": "remove" }
        ],
        "type": "modifyHeaders"
    },
    "condition": {
        "domainType": "thirdParty",
        "excludedInitiatorDomains": [
            "google.com",
            "android.com",
            "blogger.com",
            "chromium.org",
            "gmail.com",
            "googleblog.com",
            "youtube.com",
            "ggpht.com",
            "googleusercontent.com",
            "googlevideo.com",
            "gstatic.com",
            "youtube-nocookie.com",
            "ytimg.com",
            "google.ac",
            "google.ws",
            "fonts.googleapis.com",
            "storage.googleapis.com",
            "www.googleapis.com"
        ],
        "requestDomains": [
            "mail.google.com"
        ]
    },
    "id": 1580,
    "priority": 3
}

[ghostwords]

This is not a problem in MV2 / with blocking webRequest because we keep our own tab state, and we compare the tab's (top frame's) host to request hosts when determining party-ness.

In MV3 / DNR, if I add the initiator domain of the page with the mailto link to excludedInitiatorDomains, the problem is resolved. This is obviously not a tenable workaround¹, just evidence of what exactly we're running into.

Footnotes

1. We cannot enumerate all domains that host pages with mailto links. ↩