Cloudflare 收购 Astro、访问链接颜色不一致以及 1Password 语法高亮错误。
自从我上次在这里写文章以来，有三件事引起了我的好奇心，让我忍不住想就此写点东西。第一件事与网站开发行业有关；第二件事与某些浏览器中访问链接的显示方式有关；第三件事则与一个浏览器扩展程序的漏洞有关，该漏洞在几周内导致一些网站（包括本网站）的代码块出现问题。
Cloudflare 收购 Astro
多年来，我使用过许多工具来构建和维护这个网站，其中最有趣的工具之一就是Astro 。这个开源框架自几年前我参与开发的测试版以来，已经取得了长足的进步；在此过程中，它在 Web 开发社区获得了广泛的支持。然而，这种支持似乎从未转化为足以维持 Astro 本身或其背后的 Astro 技术公司（该公司雇佣了 Astro 团队的大量成员）运营的收入。由此造成的资金短缺使 Astro 面临在不久的将来被弃用的风险；对于一个备受赞誉的项目来说，这将是一个令人惋惜的结局。
因此，根据双方联合发布的博客文章， Cloudflare已收购了Astro Technology 公司。虽然并非所有收购都对被收购方有利，但至少就目前来看，这笔交易似乎是双赢的。Cloudflare 获得了一个稳定且流行的开发框架（就像Vercel拥有Next.js一样），而 Astro 团队则能够继续发展和改进这个框架。
在基于 Blink 的浏览器上访问过的链接
原来我错过了去年四月的一项更改，这项更改会影响基于Blink内核的浏览器（例如 Chrome 或 Chromium）中已访问链接的颜色。在互联网早期，在特定浏览器中，未访问过的链接始终显示为亮蓝色 ( #0000ff )，而已访问过的链接则显示为紫色 ( #800080 )。更确切地说，无论用户是从哪个页面跳转到该链接，已访问过的链接都会显示为紫色。
例如：如果您在foo.com上点击了指向bar.com的链接，那么只要浏览器保留了该次访问记录，您在其他任何页面上（而不仅仅是foo.com上）都会看到这个bar.com链接显示为紫色。当然，随着时间的推移，网站在链接颜色方面变得更加多样化，但这种行为仍然保持不变。
或者说，至少在去年四月 Chromium 136 发布之前是这样的。现在，任何基于该版本或更高版本的浏览器，只有当访问来自你当前浏览的网站时，你才会“看到”该链接已被访问。谷歌将这一变化归因于加强浏览器安全性的需要，当时包括Bleeping Computer和Tom’s Guide在内的多家网站都对此进行了报道。
截至撰写本文时，只有基于 Blink 内核的浏览器（如 Chrome 和 Chromium）以这种方式显示已访问的链接； Gecko和WebKit内核的浏览器何时或是否会效仿 Chromium 项目的做法，还有待观察。
1Password与代码块的比较
大多数密码管理应用都有自己的浏览器扩展程序，方便用户在需要时输入密码。每个扩展程序都会在发送到浏览器的内容中注入一些额外的代码。通常情况下，这不会影响网页的显示效果，但上个月1Password浏览器扩展程序更新后，这种情况持续了几周。
有问题的版本 v.8.11.23.x 完全破坏了某些（但不是全部）网页上的语法高亮显示，这些网页包含类似这样的代码块，其中显示了一些 CSS 代码：
. sitemap-div { margin : 0 auto ; width : 90 % ; }
启用有缺陷的扩展版本后，至少在我的网站上，代码块看起来像这样：
至于原因，这里有一个例子，展示了 1Password 的漏洞对Hugo和Chroma组合造成的损害。这是我用 Hugo 生成的页面上特定代码块在 HTML 中的正常显示效果：
< div > < div class = "highlight" > < pre tabindex = "0" class = "chroma" > < code class = "language-plaintext" data-lang = "plaintext" > < span class = "line" > < span class = "cl" > /Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo </ span > </ span > </ code > </ pre > </ div > </ div >
……这是在当时存在漏洞的 1Password 扩展程序处理完同一代码块后生成的 HTML 代码：
< div > < div class = "highlight" > < pre tabindex = "0" class = "chroma language-plaintext" > < code class = "language-plaintext" data-lang = "plaintext" > /Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo </ code > </ pre > </ div > </ div >
那些缺失的span元素显然造成了很大的影响，在pre元素的class声明中插入虚假的language-plaintext也造成了很大的影响。
不出所料，这个漏洞很快就在 1Password 社区论坛上引发了热烈的讨论，用户们纷纷发帖抱怨，并附上截图，诉说着这个漏洞是如何“毁了他们的网站”。究竟发生了什么？根据我在论坛内外看到的各种评论，似乎是这个存在漏洞的版本注入了基于 JavaScript 的Prism语法高亮器。这段额外的代码显然是某个版本间开发测试中遗留下来的。虽然有些网站侥幸逃过一劫，但这个漏洞显然与其他许多页面的语法高亮代码产生了样式冲突。
尽管 1Password 团队很快承认了这一问题，但直到几天后，才发布了 v.8.11.27.x 版本的修复程序，该版本首先在 Chrome 网上应用商店发布，随后又在 Firefox 和 Safari 的相应“应用商店”发布；直到v.8.12.0版本，发行说明中才提到了该修复程序：
我们修复了 1Password 扩展程序可能会导致某些网站上的代码块语法高亮显示出现问题。
-
此次延迟可能主要是由于部分 1Password 开发人员在假期期间休假所致。逾越节/圣诞节/新年假期几乎从来都不是修复任何问题的最佳时机，浏览器扩展程序也不例外。