crates.io 不能正常显示 popup
Closed this issue · 10 comments
看了下,这种使用了 webmanifest 的网页如果限制像这个站点这么严格的话,只能使用工具栏的翻译面板了,内嵌和内联样式都无法生效。
另外,开发中的 v2.0 版本计划开放翻译结果模板的自定义功能。
结合你提供的文档和 webextension 的 tabs 接口,感觉还是规则还是取决于网站,就像火狐的扩展市场一样,禁止任何注入,crates.io 貌似对脚本没有什么限制,右键菜单的翻译还是可以得到结果的,只是没有样式。
没有用过 webmanifest 在 2.0 版本中会尝试寻找解决方案,或者提供其它替代方案,比如右键菜单弹出工具栏面板。
可以使用 webRequest 修改响应头,解除网站的 CSP 限制
Firefox 和 Chrome 都从浏览器级禁止对 AMO 和 Web Store 注入 Content Script,防止扩展篡改这个商店下到有危害的扩展。
自定义弹出面板样式我觉得没有啥意义,在现在基础上优化一下就行:
- 有些页面面板内样式会有问题,建议先使用 #id * { all: inherit } 避免受网站影响
- 百度段落翻译时弹出面板宽度太窄,导致翻译内容溢出视口
试用了几个翻译扩展,这个比较好用,就是 Google 不能段落翻译比较糟心(觉得其他翻译质量不行)
谢谢作者
学到了 ( •̀ ω •́ )✧
关于自定义结果面板,样式是其次,主要是对翻译结果的自定义,因为支持不同的翻译源,强行扭在一起会丢失它们各自的优势,而且也不容易。
我并非是专职的开发人员,没办法一直维护更新这个项目,所以想通过开放 翻译源的api 和 翻译结果,在一套默认模板开箱即用的基础上,给提供用户自定义的特性,类似油猴或者样式修改器那样,让这个扩展成为一个”壳子“,即便将来翻译源的api变动,也可以手都修改配置来保持可用性,不用等待项目的更新和 AMO 的审核(曾经经历过最慢将近两个月的审核期,,ԾㅂԾ,,)。
这周内大概可以完成第一版然后提交审核
虽然修改网站的响应头是可以解除 CSP 限制的,但是经过刚刚我的测试,Firefox 在当 CSP 中的 style-src 命令中没有包含 'unsafe-inline' 时有个奇怪的行为:
- webpage 中无论用什么方式都不能正常解析 style 标签(符合预期)
- web extension 中的 content script 中使用 style.innerHTML 添加到 style 标签时能正常解析,而使用 style.appendChild(document.createTextNode())时不能正常解析
Chrome 在 content script 无论用什么方式添加到 style 标签都可以正常解析
我刚刚测试时用了 rollup 的 postcss 插件,它将 import .css 编译成 style.appendChild(document.createTextNode()) 的方式。
还没用过 rollup, 去了解了下,似乎是用 style 标签注入到 head 中,扩展现在的做法类似,直接请求一个扩展文件中的 css 文件,然后生成 style 标签注入网页中,我有点怀疑是不是应该使用官方的 tabs.insertCSS()
配合修改响应头。
如果不是非必需的话,我不太愿意去做会触发 CSP 的事情,感觉每次添加 csp 权限都会审核比较长的事件╯︿╰,所以就都去掉了,现在 v2 版本的模板功能完全用 json 然后二次编译来做了。
晚些时候我去测试一下你提供方案,火狐的 webextension 的坑都让人有些麻木了,从开发这个扩展以来,每次更新都要出点症状,有些你去 hack 后,下次就它更新 api 文档了,,,
https://bugzilla.mozilla.org/show_bug.cgi?id=1267027
tabs.insertCSS 和 style.innerHTML 多可以,我们的扩展用了 innerHTML,因为要支持小书签。
把提到点大概都测试了一遍,但没有发现特别不对的地方欸 (:≡
- 直接把站点响应头的
Content-Security-Policy
设置为空,不提示任何限制问题了 -
style.innerHTML
、style.appendChild(document.createTextNode())
或者我这种把字符串用DOMParser
解析后再插入都正常渲染,不知道是不是样式规则写的简单,测试只设置了 background 和 color
<wtt-container>
<style>
#weel-translate-frp, #weel-translate-frp * {
all: unset !important;
}
</style>
<div id="weel-translate-frp">
<div>P: {{phonetic_dest}}</div>
<div>T: {{translation}}</div>
<div>E: {{explain}}</div>
</div>
</wtt-container>
- 如果不修改响应头的 CSP 规则,直接在扩展的 manifest 中 “content_script” 设置 css 引用文件,站点的 CSP 规则不会作用在它的样式上,
tabs.insertCSS
还没试,不过是在这个接口文档里看到的解释,应该是同一个东西
PS:你上面提到无法翻译段落的问题,然后我就去重新检查代码,发现我测试的时候习惯性的只测试短语和单词,google 翻译会通过 \n
切开结果,其实是支持多行段落翻译的,我没有用网上流行的 &client=t
的生成 token 的方案,还以为是不支持 (/▽\),然后纠结地重写 v2 底层结果解析部分,才来及测试 CSP 的问题。
v2 版本 采用 script 和 style 都从 background 注入的方式,可以不用修改 CSP 来支持 浮动按钮/面板 的正常运作。