【建议】是否考虑加入对Edge的支持？

[balloon5]

用习惯了Edge，主要是白嫖微软的积分很爽

[dot4040]

Edge 实测报告 — dsh-browser 在 Microsoft Edge 上可用（附安装器缺口与 B 站特例）

---

结论：扩展本体在 Edge 上可直接运行，无需改代码

在 Edge 上做了完整的端到端实测，扩展与桥接均正常工作。真正的缺口只有一个：官方安装器只探测 Chrome。

测试环境

项	值
OS	Windows 11
Edge	153.0.4234.32（Chromium 内核）
DSH	0.1.5-rc.2（满足项目要求的最低运行时）
Node	v24.16.0
仓库版本	main（扩展 manifest 0.1.4，桥插件 @yuxianglin/dsh-bridge-browser@0.0.5）
扩展加载方式	Edge「加载解压缩的扩展」，目录 <DSH_HOME>\.dsh\browser-extension

1) 为什么 Edge 能直接用（代码层面的依据）

a. 面板宿主用运行时能力探测，不是构建期品牌判断（extensions/dsh-browser/src/background/index.ts）：

const sidebar = (chrome as unknown as { sidebarAction?: FirefoxSidebarAction }).sidebarAction
if (windowId !== undefined) void chrome.sidePanel.open({ windowId }).catch(() => {})
// Chrome 116+ uses chrome.sidePanel; Firefox has no sidePanel API, so the
void chrome.sidePanel.setPanelBehavior({ openPanelOnActionClick: true }).catch(() => {})

Edge 实现了 chrome.sidePanel，因此走原生侧边栏分支；sidebarAction 在 Edge 上取到 undefined，被 if (sidebar) 守卫挡住，不会抛错。

b. 桥接的免 token 回环信任只校验来源方案，不校验扩展 ID，也不校验浏览器品牌（packages/browser/bridge-browser/lib/index.js）：

if (!(isLoopbackAddress(remoteAddress) && typeof origin === "string" && origin.startsWith("chrome-extension://")) && !verifyToken(...))

Edge 扩展的来源同样是 chrome-extension://<id>，因此零配置自动发现路径对 Edge 成立。

c. manifest 只用了 Edge 官方支持的 API：sidePanel / storage / tabs / activeTab / scripting / webNavigation / alarms / notifications 全部在 Microsoft Edge 的「支持的 API」清单里；Edge 的侧边栏就是这套 chrome.sidePanel（见官方文档："Use the chrome.sidePanel API to host content in the sidebar of Microsoft Edge"）。

2) 实测证据

桥接握手 5 场景（ws://127.0.0.1:3080/ext/bridge，对当前运行的宿主实跑）：

场景	结果	判定
正确 token / 无 Origin	{"t":"hello.ok","caps":{...}}	✅
错误 token / 无 Origin	CLOSE code=4002 reason=bad token	✅ 正确拒绝
chrome-extension:// 来源 / 空 token	{"t":"hello.ok",...}	✅ 免 token 路径对 Edge 成立
https://evil.example 来源 / 空 token	CLOSE code=4002 reason=bad token	✅ 安全兜住
chrome-extension:// 来源 / 正确 token	{"t":"hello.ok",...}	✅

发现端点：GET /ext/bridge-config → 200 {"wsUrl":"ws://127.0.0.1:3080/ext/bridge"}

提示（不是问题）：普通 GET /ext/bridge 返回 404，因为它只注册了 upgrade 路由；用 WebSocket 握手才是 200。

浏览器工具在 Edge 上的实际效果：

站点	browser_list_tabs	DOM 快照 / 操作
example.com	✅	✅ 正文 + 编号元素
百度	✅	✅ 正文 + 26 个编号元素 + 输入框
GitHub	✅	✅ 完整正文 + 47 个编号元素
知乎	✅	✅ 登录页正文 + 输入框/按钮
bilibili.com（首页与搜索页）	✅	❌ 见第 4 节

标签绑定、开/关标签、导航、前进后退刷新均正常；受控标签在 browser_list_tabs 中正确显示 controlled: true。

3) 唯一的缺口：官方安装器不认 Edge

scripts/install.ps1 的浏览器探测只覆盖 Chrome/Chromium：

function Get-BrowserPath {
  $candidates.Add((Join-Path $base 'Google\Chrome\Application\chrome.exe'))
  $candidates.Add((Join-Path $base 'Google\Chrome SxS\Application\chrome.exe'))
  $candidates.Add((Join-Path $base 'Chromium\Application\chrome.exe'))
  # 回退：App Paths 只查 chrome.exe / chromium.exe
}

因此装完会打印「未检测到 Chrome/Chromium 浏览器」并提示 winget install Google.Chrome，随后提示语明确写「打开 Google Chrome（注意不是 Edge/Firefox）」。扩展本体其实已经构建好并放在 <DSH_HOME>\.dsh\browser-extension，只要不点"安装 Chrome"那一步，改用 Edge 手动加载即可。

最小改动建议（如果作者考虑加 Edge 支持）：在 Get-BrowserPath 的候选与 App Paths 回退里加 Microsoft\Edge\Application\msedge.exe / msedge.exe，并把打开扩展页的参数从 chrome://extensions 按浏览器分支成 edge://extensions。extensions 目录与桥接注册逻辑完全不需要改；本次实测是用一个独立的小脚本绕过这一步的。

4) 一个需要单独说明的站点差异：B 站 DOM 不可访问

现象：bilibili.com 的首页与搜索页（search.bilibili.com），browser_snapshot / browser_wait 均返回：

The current tab is available only through browser-level controls because its page DOM is protected or inaccessible. DOM snapshot, click, type, press, scroll, wait, and text extraction are unavailable here. Navigate, back, forward, and reload remain available.

重新加载后稳定复现；导航层可用（标题正确、URL 参数保持），只是 DOM 拿不到。

已排除的原因（逐项实查）：

嫌疑	排查结果
IPv6 环回（localhost → ::1）	排除：宿主只听 IPv4，发现端点返回 127.0.0.1
CSP 阻止 WebSocket	排除：manifest connect-src ws://127.0.0.1:* 与发现结果一致
Edge 站点级限制扩展	排除：runtime_blocked_hosts 为空，scriptable_host = http://*/* + https://*/*
IE 兼容模式	排除：Edge 配置中无 edge_ie_mode 节点
权限缺失	排除：activeTab/scripting/tabs/sidePanel… 全部已授予（active_permissions 完整）

触发路径（读扩展 bundle 得到的判定链）：扩展先尝试向页面派发操作，捕获到 Receiving end does not exist 后兜底调用 chrome.scripting.executeScript 重新注入；两者都失败才降级为这条提示。本次实测中两条错误文案都出现（The current page DOM is protected by the browser. 与 The content script could not be loaded on this page. Its DOM does not support browser operations.），说明注入在 B 站页面上确实失败。

这符合 README 里已声明的行为（"On browser-protected pages and extension stores, the model can read tab metadata and use browser-level HTTP(S) navigation... but it cannot inspect or operate the protected page DOM"），所以这大概不是 bug，而是 B 站落在了这份"受保护页面"范畴里。

无法进一步区分的原因（诚实说明）：未进入 Edge 的 edge://extensions → Service Worker 控制台，因此无法判断是 B 站自身的页面防护、还是本机已安装的其他扩展（广告拦截 / 请求头修改 / 用户脚本类）造成的注入失败。如果作者认为 B 站不该落进这个分支，这可能是唯一值得追的线索。

附：B 站搜索页的"筛选"面板本身就提示「筛选维护升级中，敬请期待」（我抓服务端 HTML 确认过），所以时间筛选只能走 URL 参数。该参数实测有效：

请求	结果中落在 2017-01-01 ~ 2018-12-31 的时间戳
?keyword=纸上的魔法使	1
?keyword=纸上的魔法使&pubtime_begin_s=1483228800&pubtime_end_s=1546300799	38（2017 年 29、2018 年 9）

5) 给其他 Edge 用户的可行做法

1. 正常跑官方安装器（它会构建扩展并注册桥接插件），在提示安装 Chrome 时选否；
2. 用 Edge 打开 edge://extensions → 开启「开发人员模式」→「加载解压缩的扩展」→ 选 <DSH_HOME>\.dsh\browser-extension；
3. 重启 dsh web（桥接是宿主侧插件，需要重启才挂载 /ext/bridge）；
4. 点 Edge 工具栏的扩展图标打开侧边栏，等待显示 Connected。回环部署无需填地址与 token。

---

说明：以上为单机实测结果，Edge 153 / DSH 0.1.5-rc.2 / 仓库 main。桥接协议行为均以实际握手输出为准。

[Lum1104]

我印象里 Chrome 和 Edge 两个的拓展可以互相用，回头我看看