Chrome 版本研究與 Git 練習

面對網頁擷圖、轉存 PDF、爬網頁、自動測試等需求，Headless Chrome 是十分可靠的免費解決方案。但由於 Chrome 屬桌面程式，實務應用上我習慣將其寫成排程程式或 Windows Service 以便掌控執行身分、執行個體數量，比直接由 IIS/IIS Express 呼叫穩定不易出錯。(延伸閱讀： 使用 ASP.NET Core 快速打造 Windows Service - 以 Headless Chrome 網頁抓圖為例 )

不過，幾個月前接到使用者報案，某個使用 Headless Chrome 抓圖的排程一夕崩壞，經過調查與對照，查出是 Chrome 從 72 升級到 73 版造成。幸運找到測試環境，重現「呼叫 Headless Chrome 的背景程序(排程、Windows Service)在 Chrome 72 版時可正常運作，一升級 73 後馬上壞掉」取得鐵證，在 Stackoverflow 發問 也得到網友證實。當時找到的鋸箭解法是將排程改用桌面登入者身分執行，並確保有使用者登入，勉強讓排程繼續運作。

最近另一個專案也遇到網頁轉存 PDF 需求，但這回得走 Windows Service，鋸箭法無效，只能出來面對。

重啟調查有了重大發現，原來這是 Chrome 73 的 Bug ( Issue 942023 )，3 月被提報，4 月初已修正好提交。想將此一發現補充在 Stackoverflow 提問，我想找出 Chrome 確實的修正版號，沒想到這個簡單的念頭，竟耗掉我大半個週末，噗!

摸索過程學到不少東西，在此記錄備忘。

Chromiumn 的 Source 位於 https://chromium.googlesource.com/chromium/src/ ，在 Github 有一份 Mirror 。

Issue 942023 討論 提到兩個 Commit：

1. Commit 200abd62a22a433cc155d6718c2718693654aa61 2019/4/4 22:57 by kylechar
   作者修正當 Chrome 由自動程序或服務啟動時，因 Thread 型別導致程式凍結無反應的問題
2. Commit 51314b0234d3ec9c730e7934d96d449850e864a6 2019/4/9 13:27 by kylechar
   上述修正通過 Merge Review，由 master 合併到 branch-heads/3729

但是由上述線索無法得知 Chrome 是從哪一版加入這個修正，只能繼續調查。

Chromium 有四種發行頻道( Release Channel )：

1. Stable Channel
   經完整測試，擁有 Chrome Team 品質保證，大約每兩週一次小改版，每六週一次主要改版
2. Beta Chennel 可預覽新功能，較 Stable Channel 提早一個月推出，約每週一次小改版，六週一次主要改版
3. Dev Channel
   適合想優先嘗試最新功能的玩家，每週更新一到兩次，有測試但 Bug 稍多
4. Canary Channel
   每日更新，不經測試，一建置好就釋出

Chrome 版本發行資訊可在 Chrome Release 查到，上面有各平台 Chrome (Android、iOS、Desktop)的更新公告，限定 Label: Desktop Update 縮小範圍，4/9 後的第一次穩定版本更新(Stable Channel Update)為 2019/4/23 釋出的 Chrome 74 ，公告附有 修改清單 ，從 73.0.3683.103 升到 74.0.3729.108 版的差異項目包含 51314b0234d3ec9c730e7934d96d449850e864a6 Commit，證實 Chrome 在 74 版發行時已修正這個問題：

如此即可得到我要的答案。但最近剛學 Git，就想順便見識 Chromium 這等規模的大型開源專案怎麼處理 Commit、Branch，沒想到一頭栽進去莫名又搞了好幾個小時。

我先下載了總容量高達 13GB 的 Chromium Git 儲存庫，內含超過一千兩百萬個物件! (而且提交修改的頻率很高，一天幾十次)

用 Sourcetree 看 Chromium 的分支線圖長這樣：(Sourcetree 操作起這麼大的儲存庫也十分吃力，每個動作都要花點時間等待載入完成)

由線圖可知所有修改直接提交到 master，無 feature 分支，除了 master 分支外，還有三個並行的主版號分支(如上圖的75.0.3770, 76.0.3809, 77.0.3832)。 新功能或修改經 Code Review 後會合併到入主版號分支，每次編譯有 Bot 程式會自動加上 Tag。

每個主版分支維持至少一天一次編譯，Canary 版為每晚更新，但以 74.0.3729 為例，蠻常出現一天編譯兩次的狀況。(註： Chromium 版號規則 ) 而 Chrome 75 版於 6/4 釋出，6/3 之後 74 版便未再更新。

git 指令補充： --simplify-by-decoration 參數 限定被 Branch 或 Tag 參考的 Commit、 --pretty 格式參數 %ai %d 顯示簽入時間與參考名稱

最後順手做了 Git 練習：

1. 找出 kylechar 在 4/4 之後的 Commit git log --author=kylechar --pretty="format:%ai %s" --after="2019-04-04T00:00:00Z"

   > git log --author=kylechar --pretty="format:%ai %s" --after="2019-04-04T00:00:00Z"
   2019-06-14 18:45:59 +0000 oopd: Update handling fatal context error.
   2019-06-14 17:21:31 +0000 Fix histograms in DirectLayerTreeFrameSink.
   2019-06-13 22:50:15 +0000 Fix Windows resize jitter with SkiaRenderer.
   2019-06-12 16:46:24 +0000 Don't try to exit already exiting GPU process.
   2019-06-11 18:14:59 +0000 Fix CopyOutputResult StructTraits.
   2019-06-10 20:03:04 +0000 Disable leaking viz_unittests on LSAN.
   2019-06-07 18:50:40 +0000 Cleanup chrome://gpu feature list.
   2019-06-06 16:23:39 +0000 Fix direct composition with SkiaRenderer.
   2019-06-06 15:39:53 +0000 Update blocking scope allowance for TaskGraphRunners.
   2019-06-06 14:49:34 +0000 Add note to Windows cross build instructions.
   2019-06-06 13:00:19 +0000 Remove ImageTransportSurfaceDelegate functions.
   2019-06-05 14:13:07 +0000 Add logging to CopyOutputResult deserialization.
   2019-06-04 14:57:35 +0000 Remove extra tests for SurfaceHitTest path.
   2019-06-03 16:17:43 +0000 ozone: Cleanup callback types.
   2019-05-29 21:07:32 +0000 Fix aura::Window::CreateLayerTreeFrameSink() DCHECK.
   2019-05-29 16:54:46 +0000 Rename [Compositor]OverlayCandidateValidatorAndroid.
   2019-05-28 17:15:30 +0000 Merge [Compositor]OverlayCandidateValidator classes.
   2019-05-28 00:58:30 +0000 Improve smooth scaling for reflected surfaces.
   2019-05-21 18:35:31 +0000 base: Cleanup callback types (part 5).
   2019-05-17 17:12:48 +0000 Add webgl_conformance_vulkan_passthrough_tests suppressions.
   2019-05-17 15:35:33 +0000 Update webg2l conformence test expectations.
   2019-05-16 17:08:18 +0000 Update webgl2_conformance_expectations.
   2019-05-16 15:22:57 +0000 Revert "Adding FastHash() function"
   2019-05-15 23:52:00 +0000 Mark webgl2 tests flaky for Windows Intel bots.
   2019-05-15 17:22:42 +0000 base: Cleanup callback types (part 4).
   2019-05-15 13:39:11 +0000 base: Cleanup callback types (part 3).
   2019-05-14 14:26:03 +0000 Revert "Roll src/third_party/pdfium 726ece1b5340..2169a778183b (1 commits)"
   2019-05-13 15:27:59 +0000 oopd: Delete win/mac code for VizDisplayCompositor disabled.
   2019-05-10 14:08:08 +0000 Don't call gfx::ToNearestRect() on non-integer RectF.
   2019-05-08 14:35:54 +0000 Small code cleanup for compositor_frame_fuzzer.
   2019-05-07 21:08:08 +0000 exo: Make Texture::Buffer a ContextLostObserver.
   2019-05-07 15:10:02 +0000 exo: Handle DidLoseLayerTreeFrameSink() for OOP-D.
   2019-05-06 22:48:57 +0000 Remove GPU.EstablishGpuChannelDuration.* UMA
   2019-05-02 15:53:36 +0000 Move Software[BrowserCompositor]OutputSurfaceTest.
   2019-05-01 22:25:52 +0000 Don't check VizDisplayCompositor feature on win/mac.
   2019-05-01 14:37:34 +0000 oopd: Handle GPU compositing failure on Chrome OS.
   2019-04-30 15:38:26 +0000 Remove kEnableSurfaceSynchronization switch.
   2019-04-29 19:01:40 +0000 Don't check VizDisplayCompositor feature on desktop.
   2019-04-26 20:15:02 +0000 Remove AdaptCallbackForRepeating() in ImportantFileWriter.
   2019-04-26 18:23:12 +0000 Add mojo interface for vsync parameter updates.
   2019-04-26 17:02:50 +0000 Use SharedImageInterface in GLOutputSurfaceOffscreen.
   2019-04-24 14:51:20 +0000 base: Cleanup callback types (part 2).
   2019-04-16 21:19:47 +0000 Change how vsync parameter updates are plumbed.
   2019-04-04 22:57:13 +0000 Make VizCompositorThread TYPE_DEFAULT on Windows.

2. 找出訊息出現 VizCompositorThread 字眼的 Commit

   > git log --pretty="format:%ai %s" --grep="VizCompositorThread"
   2019-06-06 08:58:59 +0000 [ozone/wayland] Fix broken software rendering path.
   2019-04-04 22:57:13 +0000 Make VizCompositorThread TYPE_DEFAULT on Windows.
   2019-01-16 22:31:28 +0000 ozone: scenic: Use IO message loop for VizCompositorThread
   2018-08-16 21:46:23 +0000 Use VizCompositorThreadRunner in VizMainImpl.
   2018-08-03 00:35:30 +0000 Reland "Add in-process VizCompositorThread for software compositing."
   2018-08-02 18:38:14 +0000 Revert "Add in-process VizCompositorThread for software compositing."
   2018-08-02 17:49:25 +0000 Add in-process VizCompositorThread for software compositing.
   2018-03-09 22:53:00 +0000 Roll src/third_party/catapult/ e490e96cd..21ff400bb (3 commits)

3. 顯示指定的 Commit 內容

   > git show 200abd62
   commit 200abd62a22a433cc155d6718c2718693654aa61
   Author: kylechar <kylechar@chromium.org>
   Date:   Thu Apr 4 22:57:13 2019 +0000
   
       Make VizCompositorThread TYPE_DEFAULT on Windows.
   
       When Chrome is launched by a service in a console session, which seems
       to how Chrome is launched from some automation frameworks, creating a
       message only window for MessagePumpForUI fails in the GPU process. As a
       result VizCompositorThread fails to run any tasks and nothing is ever
       drawn, see https://crbug.com/942023.
   
       The display compositor thread was originally made TYPE_UI on Windows in
       https://crrev.com/c/1025954. This was to allow using a child HWND
       created in the GPU process for software composited output. That code was
       deleted in https://crrev.com/c/1450399 so the thread shouldn't need to
       be TYPE_UI anymore.
   
       Bug: 942023
       Change-Id: I2a7dbf46a3a772b5ab1a9a20367d3e7f08116cbc
       Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1549763
       Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
       Commit-Queue: kylechar <kylechar@chromium.org>
       Cr-Commit-Position: refs/heads/master@{#647967}
   
   diff --git a/components/viz/service/main/viz_compositor_thread_runner.cc b/components/viz/service/main/viz_compositor_thread_runner.cc
   index 076546e6b966..bc76bac5f127 100644
   --- a/components/viz/service/main/viz_compositor_thread_runner.cc
   +++ b/components/viz/service/main/viz_compositor_thread_runner.cc
   @@ -49,10 +49,7 @@ std::unique_ptr<VizCompositorThreadType> CreateAndStartCompositorThread() {
      auto thread = std::make_unique<base::Thread>(kThreadName);
   
      base::Thread::Options thread_options;
   -#if defined(OS_WIN)
   -  // Windows needs a UI message loop for child HWND.
   -  thread_options.message_loop_type = base::MessageLoop::TYPE_UI;
   -#elif defined(USE_OZONE)
   +#if defined(USE_OZONE)
      // We may need a non-default message loop type for the platform surface.
      thread_options.message_loop_type =
          ui::OzonePlatform::GetInstance()->GetMessageLoopTypeForGpu();

   以及

   > git show 51314b0
   commit 51314b0234d3ec9c730e7934d96d449850e864a6
   Author: kylechar <kylechar@chromium.org>
   Date:   Tue Apr 9 13:27:32 2019 +0000
   
       Make VizCompositorThread TYPE_DEFAULT on Windows.
   
       When Chrome is launched by a service in a console session, which seems
       to how Chrome is launched from some automation frameworks, creating a
       message only window for MessagePumpForUI fails in the GPU process. As a
       result VizCompositorThread fails to run any tasks and nothing is ever
       drawn, see https://crbug.com/942023.
   
       The display compositor thread was originally made TYPE_UI on Windows in
       https://crrev.com/c/1025954. This was to allow using a child HWND
       created in the GPU process for software composited output. That code was
       deleted in https://crrev.com/c/1450399 so the thread shouldn't need to
       be TYPE_UI anymore.
   
       Bug: 942023
       Change-Id: I2a7dbf46a3a772b5ab1a9a20367d3e7f08116cbc
       Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1549763
       Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
       Commit-Queue: kylechar <kylechar@chromium.org>
       Cr-Original-Commit-Position: refs/heads/master@{#647967}(cherry picked from commit 200abd62a22a433cc155d6718c2718693654aa61)
       Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1559912
       Reviewed-by: kylechar <kylechar@chromium.org>
       Cr-Commit-Position: refs/branch-heads/3729@{#739}
       Cr-Branched-From: d4a8972e30b604f090aeda5dfff68386ae656267-refs/heads/master@{#638880}
   
   diff --git a/components/viz/service/main/viz_compositor_thread_runner.cc b/components/viz/service/main/viz_compositor_thread_runner.cc
   index 9585baf7845f..6e0a544f2695 100644
   --- a/components/viz/service/main/viz_compositor_thread_runner.cc
   +++ b/components/viz/service/main/viz_compositor_thread_runner.cc
   @@ -49,10 +49,7 @@ std::unique_ptr<VizCompositorThreadType> CreateAndStartCompositorThread() {
      auto thread = std::make_unique<base::Thread>(kThreadName);
   
      base::Thread::Options thread_options;
   -#if defined(OS_WIN)
   -  // Windows needs a UI message loop for child HWND.
   -  thread_options.message_loop_type = base::MessageLoop::TYPE_UI;
   -#elif defined(USE_OZONE)
   +#if defined(USE_OZONE)
      // We may need a non-default message loop type for the platform surface.
      thread_options.message_loop_type =
          ui::OzonePlatform::GetInstance()->GetMessageLoopTypeForGpu();

來個 Git 觀念題，200abd62a22a433cc155d6718c2718693654aa61 與 51314b0234d3ec9c730e7934d96d449850e864a6 這兩筆 Commit 個別查 SHA1 都查得到，但 git log 搜索關鍵字 VizCompositorThread 時卻只看得到 200abd6，為什麼？

原因是 200abd6 在 master 分支，51314b0 位於 branch-heads/3729 分支，在 master 分支查詢 git log 只會看到 200abd6。由於 Clone 複製的儲存庫並不存在 branch-heads/3279 分支，無法直接切換分支，但要看到 51314b0 不難，我們有 74.0.3729.xxx Tag，git checkout 74.0.3729.108，再下 git log，51314b0 就現身囉~

This article give a brief of Chromium release channels and source branching strategy.