且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

修改内置newtab页面

更新时间:2023-12-01 19:22:40

问题 是 Chrome 61 及更新版本 明确禁止通过内容脚本或任何其他 API 访问其内置新标签页 (NTP) 的内容.

The problem is that Chrome 61 and newer explicitly forbids access to the contents of its built-in new tab page (NTP) via content scripts or any other API.

解决方案是在扩展程序中将整个替换页面创建为 html 文件,并在 chrome_url_overrides.

The solution is to create the entire replacement page as an html file in your extension and specify it in chrome_url_overrides.

至于为什么,这里引用 [source] rdevlin,chrome 扩展 API 的开发者之一:

As for why, here's quoting [source] rdevlin, one of the developers of chrome extensions API:

这种变化有几个原因.一是执行政策,另一个是为了一致性.

There's a few reasons for this change. One is to enforce policy, the other is for consistency.

  • 一段时间以来,我们制定了公共政策,其中指出修改不允许通过 Chrome URL 覆盖 以外的任何方式访问 NTP(尽管在许多情况下,我们直到 7 月 1 日才开始执行此政策).这是只是使 chrome 代码更符合相同的政策,以帮助防止如果扩展正在修改 NTP 并因策略而被删除,则令人惊讶违规行为.
  • 这也是为了一致性,因为我们实际上已经处理了 NTP 上的脚本由于某些 NTP 魔法,多年来有所不同.比如看到的网址NTP 上的浏览​​器是 chrome://newtab,但渲染器中的 url 是https://www.google.com/_/chrome/newtab.由于 chrome.tabs.executeScript 检查浏览器中的 URL,脚本将被拒绝,即使内容脚本(在渲染器中检查)将被允许.理论上,这些权限应该不会有所不同.同样奇怪,如果用户使用的是本地 ntp(chrome-search://local-ntp/local-ntp.html),注入已经是在渲染器和浏览器中都不允许.而且,如果我们回去,NTP 曾经是纯 WebUI,其 URL 为 chrome://newtab,其中注入再次被禁止.而不是有不一致的行为取决于扩展使用的脚本注入类型,我们希望保持一致性整个系统.
  • We've had a public policy for awhile now that states that modification of the NTP through anything other than Chrome URL overrides isn't allowed (though we didn't begin enforcing this policy in many cases until July 1st). This is merely bringing chrome code more inline with that same policy to help prevent surprise if an extension is modifying the NTP and is taken down for policy violations.
  • This is also for consistency, since we've actually treated scripts on the NTP differently for years now, due to certain NTP magic. For example, the URL seen by the browser on the NTP is chrome://newtab, but the url in the renderer is https://www.google.com/_/chrome/newtab. Since chrome.tabs.executeScript checks the URL in the browser, the script would be denied, even though content scripts (checked in the renderer) would be allowed. In theory, these permissions should not be different. Similarly odd, if the user is using the local ntp (chrome-search://local-ntp/local-ntp.html), injection would already be disallowed in both the renderer and the browser. And, if we go waaaaay back, the NTP used to be pure WebUI with an URL of chrome://newtab, where injections were again disallowed. Rather than have inconsistent behavior depending on the type of script injection the extension uses, we want to have consistency throughout the system.

附言请不要编辑引用的文本.

P.S. Please don't edit the quoted text.