我的Chromium Committer之路
本文作者：weidongliu，腾讯WXG工程师
背景
Chromium是由谷歌维护的开源浏览器引擎项目，目前世界上大多数浏览器都是基于该引擎进行开发的，包括桌面端很多的其他浏览器，另外Chome, Edge, Electron等也是Chromium内核。
我作为 Win/Mac 小程序小游戏框架（WMPF）的开发和 Win/Mac 微信内置浏览器（XWeb）的开发，参与到了Chromium的“魔改”当中。
当然不论是 XWeb 还是 WMPF，都不是从chromium改过来的，而是基于 chromium项目的//content 重新实现业务层。
成为Committer的要求
和一般的开源项目的要求不同，大型的开源项目都有两种身份 Contributor 和 Committer.
只要你为Chromium提交了合入，你就是Contributor。从官方bugs论坛看到自己的Contributor身份，需要edit-bug-access权限。
当然因为我现在是committer了。所以我这里显示是committer, v8那里显示是Contributor。
但是如果你想成为committer，那么你将需要面临非常多的挑战。chromium有着极为严苛的代码审查，全面的测试以及提名要求（来源于这里的谷歌翻译）：
在Chromium src Git 存储库中贡献 10-20 个 non-trivial 补丁，并让至少三个不同的人来审查它们（您需要三个人来支持您）。然后请某人提名您。你基本上是在展示你的：
- 对项目的承诺（10+个好的补丁需要您大量的宝贵时间），
- 与团队合作的能力，
- 了解团队的工作方式（政策、测试和代码审查流程、 所有者 文件等），
- 了解项目的代码库和编码风格，以及
- 编写优秀代码的能力（最后但同样重要的）
当前提交者通过向 committers@chromium.org 发送包含以下信息的电子邮件来提名您。请不要抄送提名电子邮件中的被提名者。
- 你的名字和姓氏
- 您的电子邮件地址。如果您还没有 @chromium.org 电子邮件地址，您此时也可以要求获取（见下文）。
- 解释为什么你应该成为一名提交者，
- 包含补丁的修订版链接的嵌入列表（大约前 10 名）
另外两名提交者需要支持您的提名。提名后 5 个工作日（美国），或讨论中最后一条消息后 2 个工作日（美国），以较晚者为准，您就是提交者。如果有人反对或想要更多信息，提交者会进行讨论并通常达成共识。如果问题无法解决，当前提交者将进行投票。
这通常不会超过两周。(如果超过两周就说明你失败了🐶)
第一个CL
相信对于很多参与chromium项目的人来说。开始第一个CL往往是最难的，因为这个时候不自信，不知道什么样的提交可以被chromium社区接受。
在过去的几年当中，在我们的团队也有修复一些chromium 的 bug, 但是由于不熟悉chromium社区的政策以及相关的规定, 我们都没有尝试向chromium 提交修复。这里多亏了@royle 摸索出了提交的规则。
在今年3月份。内置浏览器正式上线之后。我发现了第一个可以提交的问题，当然现在看起来它是相当简单的一个修复。
正式开始贡献
在第一个CL之后。就是一些小小的修修补补。当我来到7个 CL的时候. 我意识到我必须找一个切入点来获取committer的支持。而且我也需要一个committer来为我解答什么样的补丁是 non-trivial 的。
有幸在9月份，我找到了//ui/views正在经历的一场重大变革：视图从无界布局转为有界布局。这最后也为我成功获得committer的支持的基础。
也因此，我结识了主要负责这块重构的Owner: kerenzhu. Keren 在整个过程中，为我解答各种疑惑，以及指出了哪些属于non-trivial.
在这之后，我积极参与//ui/views可以合入的问题。最后成功获得了kerenzhu的提名以及sky和thakis的支持。
几个重要的CL
在这里我单独列出我认为给chromium带来重大影响的合入。
1 、Add SetSupportedScheme for WebUIDataSource.
为第三方使用WebUI 奠定了基础，从此之后WebUI不再是chrome独有的方案。第三方(微信) 也可以通过指定支持的scheme来基于content实现。在这之前，你必须侵入到content以下去做这件事情。这为我们维护升级带来了困难。
2 、4929586: Fix mojo connection for non-broker browser process and child process in ipcz mode.
chromium 在lacros 平台上支持外部应用控制chrome的一些能力（当然需要你增加代码支持。它只是提供一个接口）微信就是通过这个接口来控制browser进程的行为。但是在M116上这个能力失效了。这是一个修复。
3 、5076795: Reland "Fully allocate space when there is a size mutation in the custom flex rule."
chomium 视图从无界布局转向有界布局的基础。我重写了视图的FlexLayout算法
技术拓展
Add SetSupportedScheme for WebUIDataSource.
说起来这个CL是我主动找到chromium社区的。在当时我非常看好webui的未来。我个人甚至认为WebUI是大前端下，C++和H5最好的结合的示例。为什么我如此看好WebUI.
首先，我们来看一下什么是WebUI?
如你所见，你在Chrome中看到的首页，历史记录页，设置页等等，都是WebUI. 而且首页由于chromium的特殊设置，多开首页的速度远高于其他网页，这点你可以在你的Chrome中验证。
从技术上来说，我认为WebUI是更高级的Electron(我甚至认为这才是大前端的最终形式), chromium 官方有一篇文章详细介绍了WebUI.
简单来说就是。H5仅用于UI渲染，核心逻辑都在权限更高的browser进程执行并使用C++代码实现，跨进程通信使用mojo 实现。而Electron在browser侧是使用node执行，跨进程通信使用基于mojo的 string 解析。
所以从理论上来说，WebUI有更高的性能优势。而且由于WebUI是chromium官方的实现，它有更完整的安全限制。支持renderer进程沙箱（我们团队已经支持在完整沙箱的renderer中使用node，并有成熟的解决方案，小程序/小游戏/多Tab版本下的视频号都在使用）。
基于这个背景，我极力要求Chromium社区支持我们可以自定义WebUI的使用。
最终，负责content层安全的Nasko Oskov 同意了我的请求，为此我开始实现这个功能。
在这个实现中，我一开始觉得，这不是一个很简单的修改嘛。但是最后才知道，最难的点其实不在于实现功能本身，而是实现功能的browsertest测试. 因为我需要第三方的scheme成为标准scheme,以确保url解析在各进程正常运行。
最开始，WebUI 基础架构OWNER: Giovanni Ortuno Urquidi 不赞成我通过命令行传递注册标准scheme的方法(这是在测试代码中，chromium都要求我不能这么做，我当时觉得真的是太严格了)。
最终我、Nasko 和 Giovanni 经过一周的尝试。实在无法找到其他解决方案，他们才同意了命令行传递的修改。这个简单的修改经过一个月才合入。
Fix mojo connection for non-broker browser process and child process in ipcz mode.
21年2月，chromium因为自己的需求，在lacros上支持了外部进程可以控制browser进程的需求，为browser进程提供了外部mojo接入方案
XWeb 在10月份准备升级到M116. 在这个过程中我们发现browser进程和子进程无法建立连接。
为了解决这个问题，我开始着手调查。
首先我们介绍下什么是mojo.
Mojo 是Chromium的跨进程/跨线程通信解决方案，从2015年开始。chromium的所有跨进程/跨线程消息都从传统的IPC切换到Mojo。具体的相关文章请自行查看mojo官方文档
而从M107 到 M116的过程中。mojo 从mojo core切换到了ipcz. 这导致browser进程无法作为非broker进程工作。当时经过一系列的调试，找到了相关的代码，以及对应的bugs. 原来Ken Rockot （ipcz 的负责人）其实也注意到了这个问题，他已经完成了mojo中的实现。我只需要完成content层的实现即可。
Fully allocate space when there is a size mutation in the custom flex rule
这是chromium从无界布局转向有界布局的基础。
什么是无界布局？
如果你使用过chromium ui. 那你应该会知道。其实目前的chromium ui子视图的主尺寸是不关心父视图的大小的，子视图的主尺寸总是按照自己的规则设定。但是这为chromium带来了一系列的问题。主要体现在多行标签上。
为了支持多行标签, chromium ui 引入了非常hack的操作，你需要在布局开始前，指定视图的最大宽度，否则你的视图将总是一行的。而布局中，宽度总是不断变化的，这也导致多行标签必须经历两次布局才能真正布局完成。而多行标签和其他布局引擎的组合，产生了各种棘手的问题。
终于，在22年7月份，Kerenzhu发起了布局的重构，但是他修复了TableLayout + 多行标签的组合问题之后，就没有后续了。直到我9月份看到这个bugs, 因为该bug已经有owner, 按照chromium的规则，我需要先询问owner的意见。
Keren同意我参与开发，当时我想的是，这么简单的问题，换个函数的事情，随随便便就给他搞定了。没想到后续迎来了当头喝棒。当天我提交了两个CL, 一个是FillLayout的迁移，一个是FlexLayout的迁移。
哪知道我的第一个相关的CL（FillLayout）就遇到了像素（pixeltest）测试无法通过的问题。
我当时相当确定修改没有问题，但是就是无法通过测试。当时Keren一直认为是我的问题。因此他开始查看我的第二个CL(FlexLayout). 然后FlexLayout也失败了。Flexlayout的失败更多。当时Keren始终认为FillLayout 是我的代码问题，而我当时没有CQ+1的权限，我需要Keren帮我运行测试，所以我只能从Flexlayout的失败入手。
最终发现是ChromiumOS Ash 的代码在这里其实已经遇到了多行标签导致的问题（因为Chromium OS 的编译环境复杂，我家里是没有相关机器的，只能通过代码审阅的方法查找问题，当然我经常这么干，所以这个问题不大），解决方案比较hack，无法适应我的修改。
这是我后面找到问题并修改了。Flexlayout 和 FillLayout都成功合入。
从这里开始。我真正开始被Keren认可，Keren 也为我申请了运行测试（全量测试，包括单元测试，browsertest, pixeltest）的权限，因为Flexlayout的修复当时是临时解决方案，不解决这个问题，无界布局将始终无法转向有界布局。所以我打算继续处理后续的问题。
views 的 FlexLayout 是一维算法，在一维上比CSS flex 更复杂，视图需要支持在空间不足时隐藏。以及多种views独有的特性，但是总体上，视图的灵活尺寸分配是一致的，我想到查看了LayoutNG FlexiableBox 的实现，为此看了很多LayoutNG 的知识。
我花了一周的时间（下班时间和周末）查看blink FlexiableBox 的实现，以及现存的Flexlayout 的实现，还有W3C FlexLayout算法标准。
功夫不负有心人，我最终终于找到了W3C FlexLayout 算法和views Flexlayout 结合的解决方案。
原来的views Flexlayout将布局分为两个阶段，第一阶段，处理空间不足情况下的视图分配。第二阶段处理空间过剩时的视图分配。他们有着不同的逻辑。
但是新的FlexLayout算法删除了这种不同。因为不管空间是否充足，在分配上，它仍然是遵循W3C标准算法的。
只是由于views独有的特性，我们的视图会在空间小于最小尺寸时隐藏，所以我们会留下无法分配的空间。因此我们仍然需要两个阶段的布局，但是两个阶段使用相同的算法。
总体上来说，大部分地方的分配逻辑都是没有变化的。主要变化还是发生在空间不足时，视图如何退出的问题。旧算法只要新分配的空间小于0就会退出。但是新算法还需要满足CSS视图退出规则才会退出。
这又花了我两周的时间（仍然是下班时间和周末）实现新的FlexLayout算法，以及解决单元测试和像素测试的问题. 最终经过长达一周的Code Review, 最终合入到了主线。
结语
真正的参与到chromium一个修改的时候，和之前的修修补补的感觉完全不同，我现在手上已知的可以修改的CL已经非常非常多了。我不再需要去手动的找修复。仅我目前已知的问题，应该都够我提交好久了。
参与Chromium给我带来了很多技术上的提升，以及对待编程的态度，对待他人提问，和他人的合作上，对我来说确实是一次个人的升华。
欢迎感兴趣的同事来找我了解相关的问题。
感谢 @halenhuang 针对本文的一些建议和刊误。