对于Chrome DevTools扩展,是否有预处理器脚本的替代方案?

使用Chrome调试协议。

首先,使用 DOMDebugger.setInstrumentationBreakpoint 具有 eventName: "scriptFirstStatement" 作为参数,为每个脚本的第一条语句添加断点。

其次,在调试器域中,有一个名为 scriptParsed .听一听,如果有人叫你,用 Debugger.setScriptSource 更改源。

最后,致电 Debugger.resume 每次使用 setScriptSource .

半伪码示例:

// Prevent code being executed
cdp.sendCommand("DOMDebugger.setInstrumentationBreakpoint", {
  eventName: "scriptFirstStatement"
});

// Enable Debugger domain to receive its events
cdp.sendCommand("Debugger.enable");

cdp.addListener("message", (event, method, params) => {
  // Script is ready to be edited
  if (method === "Debugger.scriptParsed") {
    cdp.sendCommand("Debugger.setScriptSource", {
      scriptId: params.scriptId,
      scriptSource: `console.log("edited script ${params.url}");`
    }, (err, msg) => {
      // After editing, resume code execution.
      cdg.sendCommand("Debugger.resume");
    });        
  }
});

上述实现并不理想。它可能应该侦听断点事件,使用关联的事件数据找到脚本,编辑脚本,然后继续。收听 脚本已分析 然后恢复调试器是两件不应该在一起的事情,它可能会产生问题。不过,这是一个更简单的例子。

在HTTP上,您可以使用 chrome.webRequest API 将JS代码请求重定向到包含已处理JavaScript代码的数据URL。

然而,这对内联脚本标记不起作用。它也不能在HTTPS上工作,因为数据URL被认为是不安全的。而且Chrome中的数据URL不能超过2MB,所以您无法重定向到大型JS文件。

如果每个脚本的确切执行顺序并不重要,您可以取消脚本请求,然后向页面发送包含脚本内容的消息。这将使它在HTTPS上工作。

为了解决这两个问题,您可以将HTML页面本身重定向到数据URL,以便获得更多控制。但这有一些负面影响:

1. 无法重新加载页面,因为URL固定为数据URL
2. 需要添加或更新 <base> 标记以确保样式表/图像URL指向正确的URL
3. 中断需要cookie/身份验证的ajax请求(不确定是否可以修复)
4. 不支持数据URL上的localStorage

不确定这是否有效:为了修复#1和#4,您可以考虑在Chrome扩展中设置一个HTML页面,然后将其用作基本页面,而不是数据URL。

另一个可能有效或无效的想法:使用 chrome.debugger 修改源代码。