declarativeNetRequest doesn’t block/redirect requests for website/pages with service worker

[Joshua Oconnor]

Hi,

I’m building an extension that should block all requests to twitter.com.

I’m using the declarativeNetRequest to catch all requests for pages from twitter.com and redirect them to my page in the extension.

This is the dynamic rule I’m using to redirect all request to twitter to my page:

{

"action": {

"redirect": {

"extensionPath": "/public/twitter-blocked.html"

},

"type": "redirect"

},

"condition": {

"isUrlFilterCaseSensitive": false,

"regexFilter": "https?:\\/\\/(www\\.)?twitter\\.com",

"resourceTypes": ["main_frame"]

},

"id": 1,

"priority": 1

}

I noticed that if I’m visiting https://twitter.com/home for the first time this page redirects to ‘/public/twitter-blocked.html’.

But if it’s the nth visit(n >= 2) I’m getting the response from the service worker and the page is not redirected. I guess declarativeNetRequest doesn’t catch requests going to the service worker cache.

See my attached image:

Has anyone managed to overcome this?

@google - Can you please  take a look and provide a workaround and a fix for declarativeNetRequest to also listen to requests going to service worker?

Thanks,

[Jackie Han]

I asked this question and Google engineers answered it.

See https://groups.google.com/a/chromium.org/g/chromium-extensions/c/E2lozxffYgU/m/4oaVbE5jAAAJ

Simple answer: if service worker intercept web request, declarativeNetRequest or webRequest will not work.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/31f65b9b-4af4-42c1-bc5a-e820becf16dan%40chromium.org.

--

韩国恺(Jackie)

[Joshua Oconnor]

Thanks for the reply and info.

Do you know a way to detect if a request has been served from service worker cache??

Thanks again

[wOxxOm]

This is not related to service workers.

Twitter is a SPA site (Single-Page Application) so it doesn't perform a full page load on subsequent navigation within the tab, it only modifies DOM of the current page and uses History API to change the current URL. As there is no network request for the new page (because it's not new, it's the same page), DNR won't work. Many modern sites are built this way e.g. YouTube, GitHub, this very forum group, to name a few.

To redirect such navigation you can listen to URL changes, for example in chrome.tabs.onUpdated event or chrome.webNavigation.onHistoryStateUpdated + onCommitted events, then just call chrome.tabs.update with your target URL.

The above events may trigger a bit too late so the unwanted original page may be visible for a fraction of a second. There is a reliable low-level method: add a DOM page script in your content script and override History.prototype.pushState + History.prototype.replaceState. In the future chrome.scripting.executeScript will allow running code in page context directly (via `executionWorld` parameter) without the need to add a DOM script.

[wOxxOm]

My previous message applies to twitter in the anonymous mode (I forgot my password) so maybe it's different when the user is logged in.

[guest271314]

I have not been able to get declarativeNetRequet to redirect at all.

[Cuyler Stuwe]

This isn't specific to declarative network requests, but more generally related to all network requests, as Jackie noted.

I've had to deal with this for an e-commerce extension, and I don't remember the details, but my solution essentially came down to something like injecting a script into the page to unregister the service worker, along with some code that prevented it from being re-registered.