跳到主要内容

576 个窗口玩贪吃蛇,值得点开的是评论

书签客
书签客

· 阅读约 3 分钟

这条在讲 GrahamTheDev 用 576 个浏览器窗口当像素块渲染贪吃蛇的实验——出处是他的 dev.to 文章。贪吃蛇本身是个玩笑,他自己也说是跟同事讨论"一个浏览器窗口能不能控制另一个"之后玩大了,顺着就把想法撑到了 576 个窗口。

我一开始觉得这就是个"手艺活"的奇观贴,没打算推。真正让我改主意的是后半段,他写完贪吃蛇之后转过去讲了一个实用场景:用两个窗口协作检查第三方网站里的失效链接,绕开 iframe 被禁用的问题。这个转向才是这条链接里真正有点东西的部分——玩笑是他随手搭的,后半段那个用法才像他本来想试的东西。

弹窗 API 这套东西说实话很老了。window.open 可以设置大小位置,给窗口起个名字,后面还能通过这个名字引用它、移动它、改它的 location。作者那个 576 窗口贪吃蛇跑起来就是靠这个,窗口开出来之后按方向键挨个给窗口挪位置。我没去跑 576 个窗口,那种跑法除了听风扇转没别的收获。但我把评论从头到尾读完了,评论比正文值钱。

评论里 Wren Calloway 提了一句,说跨域窗口你根本读不到它的内容、也读不到最终的 URL,只能重新赋值 location。这句话不点开评论区看不到,但它直接把后半段那个"检查失效链接"的实拍场景划了条边。原作者演示的是"让那个窗口跳转到某个地址,然后看它停在哪儿",但评论的意思是:你没法直接知道它到底停在了哪个 URL,只能亲手再确认一遍页面状态。也就是说,绕开 iframe 是对的,但绕开之后省不掉人工那一步。这个细节读完之后,我反而更想点开原文了,因为我想知道作者在评论区是怎么接的。结果那条他没正面接。

另一个评论者讲的是 Chrome 对手势的限制。异步操作之后调 window.open,窗口很可能就被拦了。这事我倒是有印象,很早以前写登录页被弹窗拦截打回去过。异步回调里开窗口这个坑,跟现在很多用 agent 自动开浏览器窗口的场景是同一个道理,不是新问题,但总有人重新踩一脚。评论区有人把这条明确写上,比正文里的演示更像实用信息。

作者的回复就一句,说自己配置高的 PC 上窗口会闪烁但还能玩。这条回复挺真实的,也几乎等于承认这实验没有其他更好的结果。576 个窗口在 Chrome 里跑贪吃蛇,能玩,也闪得厉害,既不优雅也不适合替代任何东西。会想做这件事本身就很好笑,和能做的事窄得很,这两件事并排放在那条回复里,反而更像这条链接想表达的完整意思:一个窗口确实能控制另一个,但控制得刚刚够让蛇动起来,再往前多读一点就全是限制。

不点链接也能带走的一句:window.open 是最现成的浏览器间通信通道,但这个通道只能"指路"——往哪里跳、挪到哪,不能"看结果"。跨域下想确认目标页面到底怎么回事,最后还是得人肉眼兜底。这个结论本身不新鲜,被一个 576 窗口的贪吃蛇实验顺路验证出来,倒是有点意思。

所以这条我推,不是推贪吃蛇。贪吃蛇那一部分点开就知道是什么,好玩但就那样。我推的是评论和作者后半段那个双窗口查失效链接的用法之间对出来的缝隙——正文明明展示了能控制,评论顺手把控制的边界写清楚了。这种"正文演示、评论区划界"的组合,比单独哪一部分都值得读。

书签客
书签客

只推真读过的、顺手跑个实验贴完整记录——link-blog 策展 + 实验笔记。

查看主页 →