javascript - 仅当用户单击链接打开时，才在重定向新选项卡/窗口之前阻止初始 webRequest

Question

我正在开发 Chrome 扩展程序。我想要完成的是重定向在新窗口或新选项卡中打开的超链接。我已经尝试过下面的代码，虽然这确实重定向了选项卡，但它不会阻止提交原始页面请求，这也是我想要完成的事情。

chrome.webNavigation.onCreatedNavigationTarget.addListener(function(details) {
    chrome.tabs.update(details.tabId, {
        url: 'http://www.google.com/'
    });
});

如果用户在新窗口中打开超链接(例如 shift/ctrl+click、中键单击、上下文菜单等)，我只想重定向。如果窗口或选项卡因其他原因打开，我不想重定向。

Answer 1

重定向仅由链接而不是直接打开的新选项卡/窗口

不幸的是，如果没有每个页面中的内容脚本，您就无法在传输 webRequest 之前区分用户单击链接和打开新选项卡或窗口的其他原因。
transitionType 的值清楚地指示了导致选项卡或窗口打开的 webNavigation 类型。属性，在提供给 webNavigation.onCommitted 的详细信息中听众。如果是用户点击链接，transitionType属性的值为 link .如果请求来自链接，则不是 webNavigation.onCommitted 之前的背景页面通常可用的信息。事件。

不幸的是，对于您想要的，webNavigation.onCommitted页面 URL 的 webRequest 完成后触发事件。因此，如果不通过某种方式更早地知道转换是用户单击链接的结果(例如使用内容脚本)，您就无法知道当前转换是用户及时单击链接以进行选择的结果重定向页面主 URL 的 webRequest。

您可以做的总是将初始请求重定向到 about:blank .然后，一旦你得到 webNavigation.onCommitted事件，您可以根据 transitionType 的值进行选择属性，将选项卡的 URL 更改为您最终想到的重定向 URL，或将其更改回原来预期页面的 URL。这个过程会导致丢失Referer表示单击链接的页面的标题。

显然，您可以使用您的最终目的地而不是 about:blank .这可能会更好，但即使选项卡最终被放回原始目标 URL，也会导致对该 URL 的 webRequest。

这是执行上述操作的代码:

背景.js

var tabsBlockedOnce = new Set();
var tabsRedirected = new Map();
chrome.webRequest.onBeforeRequest.addListener(function(details){
    if(!tabsBlockedOnce.has(details.tabId)){
        tabsBlockedOnce.add(details.tabId);
        tabsRedirected.set(details.tabId,details.url);
        //Redirect
        return {redirectUrl:'about:blank'};
        //Block
        //return {cancel:true};
    }
},{urls:['<all_urls>'],types:['main_frame']},['blocking']);

chrome.webNavigation.onCommitted.addListener(function(details){
    if(tabsRedirected.has(details.tabId)){
        //Default is to not redirect
        let url = tabsRedirected.get(details.tabId);
        tabsRedirected.delete(details.tabId);
        if(details.transitionType === 'link'){
            //It was a link, go to where we want to redirect.
            url = 'http://www.google.com/'; 
        }
        //Send the tab where it is supposed to go
        chrome.tabs.update(details.tabId,{url:url});
    }
});

//Don't block the first request in any tab that already exists.
//  This is of primary benefit when the extension is first installed/reloaded.
chrome.tabs.query({},function(tabs){
    tabs.forEach(function(tab){
        tabsBlockedOnce.add(tab.id);
    });
});

manifest.json(部分):

"permissions": [
    "webNavigation",
    "webRequest",
    "webRequestBlocking"
],
"background": {
    "scripts": ["background.js"]
}

每个页面都有内容脚本，你可以直接做

为了直接执行此操作(即，如果页面最终不会被重定向，则不会干扰原始 webRequest)，您必须知道 webRequest 的原因是在 webRequest.onBeforeRequest 之前单击了链接。事件触发。要及时将此信息发送到您的后台脚本，您必须在每个页面中注入(inject)一个内容脚本和 runtime.sendMessage()。向您的后台脚本发送一条消息，表明链接正在被点击。

根据测试，这样的消息会在 webRequest.onBeforeRequest 之前到达后台脚本。射击。能否使用内容脚本执行此操作取决于内容脚本与 runtime.sendMessage() 发送消息之间的异步通信的确切时间。当 runtime.onMessage事件触发与 webRequest.onBeforeRequest事件触发。测试表明 mousedown , mouseup和 click事件( click 并不总是针对所有鼠标按钮触发)可以发送后台脚本在 webRequest.onBeforeRequest 之前接收到的消息。事件触发。此时间无法保证，但似乎有效。

从用户体验的 Angular 来看，这通常是一个坏主意

您想要做的事情会篡夺用户选择使用 UI 交互来专门在新选项卡或窗口中打开链接。除非我专门寻找这个功能，否则我会觉得这很烦人，几乎可以肯定的是，我会立即卸载该扩展。篡夺用户的代理权来控制他们的机器是只有在非常有限的情况下才应该做的事情。除非您处于专业环境中，否则您所提出的建议将与大多数用户的期望相反。此外，它可能会中断与某些网站的交互。