Docker化Browserless-Chrome运行Mediawiki Selenium页面加载时挂起问题

背景 #

我编写了一份makefile，仅需执行单个make命令，即可从零开始在本地机器拉取并启动Docker化的Mediawiki实例，目前该方案运行效果良好，欢迎试用。

目标 #

我希望同样通过makefile简化操作流程，支持在Docker容器中原样运行Mediawiki的Selenium测试，同时可实时观看测试执行过程，一键启动整套流程。

实现方案 #

当前处于开发阶段的分支新增了两类容器：

• 一类用于运行Mediawiki Selenium测试
• 另一类是browserless-chrome容器，支持测试运行过程中实时查看、调试测试用例

根据分支README顶部的说明，执行make启动所有服务后，运行make runseleniumtests即可启动测试。执行该命令后会自动打开浏览器窗口，展示browserless-chrome容器中运行的Selenium测试过程，但该功能仅能部分正常工作。

问题现象 #

在若干条测试正常运行后，会出现如下报错：
Protocol error (Input.dispatchMouseEvent): Target closed.

报错似乎都在测试操作触发新页面加载时出现，初步怀疑问题根源在于browserless-chrome容器的Chrome会话管理机制，暂未确认准确原因，欢迎提供排查思路。这套makefile的设计初衷是大幅降低从零搭建环境的门槛，仅需执行少量命令即可复现测试运行过程与上述报错。

其他补充信息 #

• 测试运行失败后，在宿主机执行curl -s http://127.0.0.1:3000/sessions | python3 -m json.tool，可看到存在多个browserless-chrome会话
• 非Docker部署的环境运行触发页面加载的测试时无任何异常，暂不清楚如何调整配置让Docker化部署的表现与非Docker环境一致

在与Browserless支持团队的邮件沟通中，对方表示曾遇到过类似问题但尚未定位根因，相关反馈如下：

问题根源可能是打开实时调试器查看运行过程时，click事件无法正常工作。经确认（我已验证该现象），如果不打开实时查看器，测试可以继续推进，后续仅会抛出选择器无法找到的相关错误。

我之前也遇到过实时调试器的这类异常行为，当时我关闭了实时查看功能，因为无法看到哪个选择器未命中，我导出了运行时的截图，最终发现是视口配置问题：远程会话的视口尺寸更小，样式渲染结果与本地机器存在差异，设置正确的视口尺寸后选择器即可正常命中——但这是我当时遇到的特定场景问题，不一定适用于你的情况。

目前可以确认的是，查看实时会话时确实会偶发这类异常问题，我们暂未明确问题的具体成因。

内容的提问来源于stack exchange，提问作者Monte Hurd