网页全屏按钮显示成功却仍有地址栏，怎样以 fullscreenElement 判定

以 requestFullscreen 的 Promise 和 document.fullscreenElement 判定网页全屏，再监听 fullscreenchange 同步界面。按钮回调已经执行或样式铺满视口，都不能单独证明浏览器已进入全屏。

网页铺满与全屏状态不同

把元素设成fixed并铺满视口只是CSS布局，地址栏和浏览器界面仍可能存在；Fullscreen API则有独立状态和权限条件。附件通过真实按钮点击请求documentElement全屏，Promise成功后断言fullscreenElement就是该元素，再主动exitFullscreen并等待状态变为null。整个过程不依赖一张截图猜测是否出现浏览器外框。

成功与退出都应驱动界面

全屏可能由用户按退出键、浏览器行为或文档变化解除，不能仅在自己的退出按钮里把状态改回去。fullscreenchange回调应重新读取fullscreenElement，必要时显示重新进入提示。请求拒绝时保存错误名称并留在普通布局，不要把按钮文案直接写成已经全屏，或无限自动重试一个需要用户激活的操作。

输入与权限条件写清楚

本例入口是真实浏览器按钮点击，不是人工dispatch的click，也没有试图屏蔽Escape或系统快捷键。自动化运行在本地Chromium headless，能证明API状态往返与回调，不等于肉眼检查了某台显示器是否覆盖整个物理屏幕。跨源iframe的授权属于另一条条件，需要单独验证，不能只看顶层页面的成功结果。

不能从全屏推到展台锁定

网页全屏不是Windows账户限制、系统外壳替换或运维策略。即使fullscreenElement正确，也不能宣称观众无法切换应用、退出账号或调用系统手势。若目标是无人值守展台，应把网页状态、浏览器启动方式和系统配置分别验收；本题只讨论API与页面状态，不修改用户电脑策略，也不留隐藏系统退出手段。

给全屏退出保留正常布局

退出后内容应仍可操作，按钮名称与状态回到普通模式；不要把只在fullscreen伪类里成立的尺寸留到退出状态。真实浏览器可能在用户退出后限制短时间再次自动请求，因此应由清楚的用户动作重新进入。附件主动调用exitFullscreen验证状态归零，没有测试强制系统退出、浏览器崩溃或多显示器目标选择，这些应按运行时与现场要求另外记录。

下载并复现

下载原创HTML夹具、独立验证程序、本次执行记录和依赖与运行说明，放在同一目录。安装Playwright 1.58.0及其Chromium后运行 python verify.py；程序使用两个随机本地端口，自动关闭浏览器与服务，不请求外网或业务接口。

本次实际环境为Python 3.12.4、Playwright 1.58.0、Chromium 145.0.7632.6。Playwright浏览器鼠标/键盘与页面API实跑；无实体硬件或业务控制。断言已通过；完整事件和数值保留在执行记录，不能把它改名后当目标展项测量。

继续核查与一级出处

基础背景见展厅设备开机自动全屏播放配置。顶层全屏成功后，跨源嵌入仍需单独检查授权，可继续用嵌入展项能播放却不能全屏，怎样核对 iframe 的全屏授权取证；相关工程入口在专题与产品对接说明。

• 全屏请求、状态及事件；用户激活与错误路径：2026-10-24已联网读取一级来源；WHATWG Fullscreen Living Standard，读取页标记2026-10-19更新。