"SCRIPT" type request ignored

[wjtk4444]

Expected behavior

a script that modifies href gets caught by redirect rule with "ANY" or "SCRIPT" request type

Actual behavior

rule is ignored

Steps to reproduce the problem

• visit www.youtube.com (either main or any other page, doesn't matter)
• click on any channel's name
• see the rule being ignored
• press F5 (or use any other method to reload the url)
• see the rule being applied

Pictue below shows the rule I'm using. Basically, it's a redirection from channel's main page to channel/videos. It does work after typing the url in address bar, but doesn't when I click "urls" (that are actually scripts, not links; at least one of the events is called yt-navigate) on the youtube itself.

Here's the regex url pattern from the screenshot: /https://www\.youtube\.com/(channel|user)\/([a-zA-Z0-9\-]+)\/?$/ and the redirection target: https://www.youtube.com{pathname/\/$/}/videos

You can ignore path patterns and check "any url" when testing - it's probably slower but works exactly the same.

[anewuser]

You didn't catch URLs with parameters, and Youtube adds parameters to those URLs. My rule works:

Host: www.youtube.com Path: * Type: Any Redirect rule: {href/(.*\/(user|channel)\/[\w_-]+)(\/|\?.*)?$/$1/videos}

[tumpio]

a script that modifies href gets caught by redirect rule

This alone is not supported, since there is no requests made that could be listened. Maybe those history state changes can be watched using webNavigation API. Or listening for "popstate" events in a in-page content script: https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event

(that are actually scripts, not links; at least one of the events is called yt-navigate)

Script type classifies requests that load scripts to document e.g. all those javascripts that will be executed by the browser when page is loaded first time. When a script in page does a request in background for example to load more content in page, that is classified as XMLHttpRequest (xhr). That is how youtube works when you click those channel links.

[wjtk4444]

@anewuser

My rule works

Does't work for me. Or rather, it works in the same way mine does.

You didn't catch URLs with parameters

It doesn't seem like there are any parameters to those urls.

@tumpio So, there's no way of working something around that? Previously I used an on-load userscript executed via Violentmonkey that just changed href, seems like Redirector does about the same because it works in this case.

[anewuser]

[wjtk4444]

@anewuser

request-control-rules.txt

It works. I'm yet to understand what exactly did you do, but it works. Thanks man. It seems that it loads the page with "initial" url and the redirect proceeds after it's loaded (just like with an userscript or the other extension that I mentioned).

@tumpio It's technically not a solution to this issue as probably completely blocking a connection that way wouldn't work, but I'm satisfied because I don't have to use another extension for this particular case. It's up to You whether this issue should be closed or not.

[tumpio]

Probably the redirection of XMLHttpRequest causes youtube to reload the page with full normal page reload (Document), which is then redirected again by the redirect rule.

You could try to block the specific XMLHttpRequest, and in the redirect rule only select the Document type for redirection. But, I'm not sure if there is any any "better" ways to handle this..

[anewuser]

@wjtk4444 I had to update the rules to make the redirection work again. As with the previous version of the extension, middle clicks on channel links work better than normal links:

request-control-rules.txt