1

I had an extension which was using the parentFrameId property on onHeadersReceived with the webRequestBlocking permission to strip specific headers for all the requests coming from the iframes of a tab.

To achieve this, the condition was: request.tabId === tabId && request.parentFrameId !== -1.

// Tab ID to instrument.
const tabId = 42

chrome.webRequest.onHeadersReceived.addListener((details) => {
  if (details.responseHeaders && details.tabId === tabId && details.parentFrameId !== -1) {
    return {
      responseHeaders: details.responseHeaders.filter( /* filter */ ),
    }
  }
}, {tabId, urls: ['*://*/*']}, [
  'blocking',
  'responseHeaders',
  'extraHeaders',
])

But with the new declarativeNetRequest API, I can't find a good RuleCondition to mimic this behavior.

I tried this:

// Tab ID to instrument.
const tabId = 42

await chrome.declarativeNetRequest.updateSessionRules({
  addRules: [
    {
      id: 1,
      action: {
        responseHeaders: [
          {
            header: 'my-header',
            operation: chrome.declarativeNetRequest.HeaderOperation.REMOVE,
          },
        ],
        type: chrome.declarativeNetRequest.RuleActionType.MODIFY_HEADERS,
      },
      condition: {
        resourceTypes: [chrome.declarativeNetRequest.ResourceType.SUB_FRAME],
        tabIds: [tabId],
      },
    },
  ],
})

But as said in the comments of this StackOverflow question, "sub_frame means the request that creates the iframe itself, not its own requests".

Do you see any condition that could mimic parentFrameId !== -1 with the declarativeNetRequest API?

Drarig29
  • 1,902
  • 1
  • 19
  • 42
  • 1
    There's no solution in DNR. The only solution is to keep using webRequestBlocking in a force-installed extension via policies or suggest the users to use Chrome-Developer-Mode-Extension-Warning-Patcher to enable webRequestBlocking in MV3. – wOxxOm Nov 14 '22 at 17:52

0 Answers0