修改内置newtab页面 [英] Modifying the built-in newtab page

问题描述

我无法在新标签页上运行我的内容脚本(它没有分配给任何 url).

I am not able to run my content script on the new tab page (where it is not assigned to any url).

我查看了有关该主题的各种帖子，即是否有内容脚本可以访问 newtab 页面吗?和 google chrome 新标签页的 URL 是什么以及如何从 manifest.json 中排除它

I looked at various posts on the subject, ie, Does content script have access to newtab page? and What is the URL of the google chrome new tab page and how to exclude it from manifest.json

这似乎表明这是可能的.

which seem to suggest it is possible.

我启用了 chrome://flags/#extensions-on-chrome-urls

I enabled chrome://flags/#extensions-on-chrome-urls

我有:

"permissions": [
    "http://*/*", 
    "https://*/*",
    "chrome://*/*"
],

(也试过"*://*/_/chrome/newtab*")

仍然没有运气......我错过了什么?

still no luck ... what am I missing ?

这个答案你能通过扩展访问 chrome://页面吗? 提及不接受通配符".这是真的 ?如果是，如何指定新标签页?

this answer Can you access chrome:// pages from an extension? mentsions "wildcards are not accepted". Is this true ? and if so how to specify the newtab page ?

推荐答案

问题 是 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.

这篇关于修改内置newtab页面的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！