当人们看到浏览器扩展添加了翻译控件,侧面板,或者向WhatsApp Web发送工作流程时,一个常见的问题是:扩展是如何与页面实际互动的?
简短的答案是,现代的Chrome扩展被分出多个执行环境.
任何单一的脚本都不应该负责界面,持续状态,任务时间安排,以及同时访问页面.
本文在实用层面解释架构,而不取决于任何WhatsApp Web更改时可能改变的私人执行细节.
浏览器扩展名不作为一个程序运行 最简单的心理模型是将扩展分为四个部分: 扩展界面 A背景服务工作者 A 内容脚本附在WhatsApp Web A小桥上,运行在页面自有的JavaScript上下文中 每一部分都有不同的工作和不同的访问级别.
扩展界面是用户看到的:窗体,任务历史,翻译设置,已保存的脚本,以及媒体选择.
它应侧重于互动而不是长期工作。
背景服务工作者协调任务和储存状态。
它可以接收来自界面的请求,跟踪进度,并将命令发送到正确的WhatsApp Web标签.
内容脚本与网页并存.
它可以检查所提供的文件,注入控制,并与扩展运行时间进行通信.
Chrome将它从页面自己的JavaScript环境中隔离出来,用于安全.
页面桥之所以存在,是因为孤立有时是一种限制.
一个内容脚本可以看到DOM,但它不会自动分享和WhatsApp Web相同的JavaScript对象.
当需要更深层次的页面集成时,仔细的放范围桥可以在被隔离的扩展世界和页面世界之间交换出明确的信息.
为什么不把所有内容都写在剧本里?
由于内容脚本已经附在WhatsApp Web上,所以将整个功能保留在一个文件中是诱人的.
这种做法很快变得脆弱。
脚本必须使界面出炉,观察页面,管理任务,存储数据,处理介质,处理重试,并活过导航变化.
当一部分失败时,就很难确定问题来自UI,任务状态,还是页面集成.
分离责任产生更清晰的故障边界:界面验证用户输入并显示状态.
背景工作者拥有任务进度。
内容脚本拥有与当前页面的视觉集成.
页面桥只执行需要页面文本访问的操作.
这种分离确实会增加消息传递,但是这种复杂性比一个有隐藏依赖性的单一脚本更容易解释.
侧面板和聊天页是独立的表面.
MSG.AI在WhatsApp Web旁边增加了一个工作空间,而不是替换页面.
面板对需要空间的操作是有用的:审查收件人列表,编辑可重复使用的脚本,查看任务进度,或者选择媒体.
小型行动,如翻译一个信息,在信息本身旁边更自然.
这就形成了两个必须保持同步的界面表面.
例如,修改面板中的目标语言应影响当前对话外的翻译行动。
支持一项任务应当同时更新背景状态和小组显示的进展。
如果用户重新装入WhatsApp Web,界面应该从持久性状态恢复,而不是发明出新的任务.
教训是,DOM注射只是作品的可见部分.
国家协调通常比较困难。
页面更改是"脆弱WhatsApp Web"的主要来源,是一个活生生的应用程序.
它不跟随第三方延期的发布周期而改变.
CSS类名称可以更改.
按钮可能会移动。
作曲家可以重建.
信息泡沫可能对媒体、引用的答复、反应或dif产生不同的影响