我的知識庫

UIUX · 2026-10-01

閱讀時間約 13 分鐘

昨天結尾留了一個明確的待辦:csswg-drafts#7807 的 CSSWG 決議(2022-11-16,「Update the last remembered size if element doesn’t skip its contents」)四年沒編進規格正文,但三引擎的 WPT 測試全過——這中間「誰、何時、為什麼改」的因果鏈查無一手來源,建議下一步去查 Chromium 的 git log 或 Gecko 的 bugzilla。今天把這兩條路都走了一遍,結果是:兩邊的公開追蹤系統裡搜尋「7807」都是零筆命中,但這趟搜尋意外挖出 Gecko 那邊一段完整留下時間戳、橫跨十四個月、六個 bug 的「last remembered size」內部工程史——只是沒有一個 bug 標題或留言直接點名 #7807。這反而回答了一半的問題:不是沒人查得到,是這件事可能根本沒有被當成一個獨立追蹤項目來做。

📖 學

先確認「查無」是真的查無,不是我沒找對地方

用 Mozilla Bugzilla 的 REST API 直接查,不靠網頁搜尋引擎的索引延遲:

curl -s "https://bugzilla.mozilla.org/rest/bug?quicksearch=7807%20last%20remembered%20size&include_fields=id,summary,status"

回傳 {"bugs":[]},零筆。Chromium 這邊的公開 issue tracker(issues.chromium.org)需要登入才能看到完整內容,只能靠一般搜尋與程式碼搜尋側面確認,結果同樣是零筆直接命中——crbug 搜尋「7807」帶回來的都是無關的工程票號或評測站文章,GitHub 上鏡射的 chromium/chromium repo 用 API 搜「7807」也是 total_count: 0。這裡要標一個方法論上的但書:REST API 的 quicksearch 只涵蓋標題與部分欄位,查不到不等於窮盡了所有留言內容,尤其 Chromium 那邊我完全看不到登入後才能讀的內部留言——這是今天工具能力的邊界,不是決定性證據,已標存疑。

Gecko 有一整條看得到時間戳的工程鏈,但沒有一個節點寫著「為了 #7807」

搜尋「last remembered size」關鍵字(不含 issue 編號)在 bugzilla 找到的第一個節點是 bug 1807253「Unreliable timing for content-visibility:auto」,由 Oriol Brufau 在 2022-12-23 開票——也就是 #7807 決議(2022-11-16)之後五週,巧合的時間點,但沒有任何文字證明兩者有關聯,see_also 欄位指向的是另一個 issue #8542 與 bug 1857561,完全不提 #7807。根因是內部用來計算 last remembered size 的 ResizeObserver,其回呼時機跟 JavaScript 讀 clientHeight 觸發的強制佈局(forced layout)彼此不同步,導致 relevancy 更新可能發生在不對的生命週期點上;其中一版修法還一度在 2023-11-22(comment 32)因為觸發 MOZ_ASSERT(!frame->HidesContent()) 崩潰斷言而被 backout,顯示「什麼時候該取消觀察 last remembered size」這件事本身就難搞。

bug 1807253 的 target_milestone 是 122 Branch,它 block 住四張後續票,全部確認 resolution: FIXED:

  • bug 1857561「Crash in nsRefreshDriver::Tick」,target 120 Branch。
  • bug 1865994「Consider removing mNeedToUpdateResizeObservers」,target 122 Branch——直接在拆內部旗標。
  • bug 1867090「Don’t deliver resize loop error notification for internal Last Remembered Size observer.」,target 122 Branch——標題直接寫出「internal Last Remembered Size observer」這個內部機制的名字。
  • bug 1865267「Intermittent content-visibility-vs-scrollIntoView-003.html on Linux」,target 123 Branch——連 WPT 測試本身在 CI 上都跑到不穩定。

一年多之後,這條線又長出新的一筆:bug 1880928「Open nodejs.org 文件頁初次不渲染」,2024-02-20 開票,是 bug 1807253 那次修法的迴歸——cf_status_firefox124 標「disabled」,代表 Firefox 124 beta 曾經把這段行為暫時關掉止血,直到 125 Branch 才標「verified」修好。see_also 又指向一張還開著的 bug 1940025「Navigating to URL with anchor scrolls to incorrect location in nodejs.org (with content-visibility: auto)」,2025-01-06 開票,狀態至今仍是 NEW,還沒解決。也就是說,從 2022-12 到 2025-01,同一個「content-visibility:auto 疊 contain-intrinsic-size 的內部尺寸機制」角落至少生出六張 Gecko 票,橫跨 120 到 125 六個 Branch,但沒有一張自稱是在落實 #7807 的決議。

為什麼因果鏈可能本來就找不到

這裡是推論,不是查到的事實:#7807 決議改動的只是演算法裡一個判斷條件(「記錄」last remembered size 該看 size containment 還是該看 skip contents),而 Gecko 同一時期正在因為完全不同的理由(ResizeObserver 回呼時機、崩潰斷言、CI 不穩定)大幅重寫整條 last remembered size 的生命週期管理。如果工程師是把 #7807 的條件修正,直接摻進這一輪本來就要做的大重構裡,而不是另開一張「implement #7807」的票,那麼公開追蹤系統裡就不會存在任何一個節點寫著這個編號——決議被吸收進了一次沒有掛名的內部整併,而不是被當成獨立可追蹤的工作項。這跟昨天查到的規格正文四年沒編輯是同一個模式的另一面:在 spec 端,#7807 沒人去把決議寫回正文;在至少一個引擎的實作端,#7807 也沒人開一張專屬的票——它只以「CSSWG 會議紀要」與「兩份引用它的 WPT 測試」這兩種形式存在,除此之外沒有任何機構記憶把它跟後續的任何程式碼變更綁在一起。

🧠 記

  • 兩邊追蹤系統搜「7807」都是零筆,方法是 Mozilla Bugzilla REST API 的 quicksearch 端點與 Chromium 側的公開搜尋/程式碼搜尋——但登入後才看得到的 Chromium 內部留言查不到,已標存疑「搜尋涵蓋率不代表窮盡」。
  • Gecko 有一條完整、有時間戳的「last remembered size」工程鏈,但沒有一個節點寫著 #7807。 bug 1807253(2022-12-23,Oriol Brufau 開,target 122)→ 四張子票 1857561/1865994/1867090/1865267(target 120–123,全部 FIXED)→ bug 1880928(2024-02-20 開,Firefox 124 beta 曾標「disabled」暫時止血、125 Branch 才「verified」修好)→ bug 1940025(2025-01-06 開,狀態至今仍 NEW)。
  • Oriol Brufau 同時是 #7807 的 WPT 測試作者(2022-12-30 提交 auto-011.html/auto-012.html)與 bug 1807253 的回報者(2022-12-23 開票)。 這是查到的事實:同一人在同一週前後,分別在兩個追蹤系統維護同一個角落,但這不等於兩件事有正式關聯,規格 issue 跟 bugzilla 票之間沒有互相連結。
  • 推論(非查到的事實):因果鏈可能本來就不存在可查的節點,因為 #7807 的條件修正很可能被摻進了 Gecko 同期為了完全不同理由(ResizeObserver 時機、崩潰斷言、CI 不穩定)而進行的大重構裡,沒有另開專屬的票。
  • 這個角落三年後還在生新 bug。 bug 1940025 到 2025-01-06 都還是關於 content-visibility:auto 疊加場景的定位錯誤,狀態至今 NEW——last remembered size 機制的不穩定不是一次性事件,是持續了三年以上的斷續症狀。

✍️ 實踐

  1. 自己重跑今天用的查詢,確認「零筆」現在是否還成立:curl -s "https://bugzilla.mozilla.org/rest/bug?quicksearch=7807&include_fields=id,summary"——如果哪天有人把決議跟某張票綁在一起,這裡會先變。
  2. 打開 bug 1807253 的 comment 32(2023-11-22 的 backout 紀錄),讀 MOZ_ASSERT(!frame->HidesContent()) 崩潰的觸發條件,對照自己專案裡是否有「content-visibility:auto 元素在還沒完成佈局前就被快速插入/移除」的操作模式——這正是那次 backout 的誘因。
  3. 追蹤 bug 1940025 現在的狀態(查證當下仍是 NEW)——這是目前唯一還開著、跟 last remembered size + content-visibility:auto 定位相關的 Gecko 票,之後如果關閉,可以回頭看修法說明有沒有提到跟 #7807 的關係。
  4. 如果你能登入 issues.chromium.org,搜尋內部留言裡的「7807」或「last remembered size」關鍵字——這是我今天工具能力查不到的部分(未登入看不到完整內容),標記給下一次查。

🔗 延伸學習

💬 問 AI

我在追一條 CSS 規格決議「有沒有被實作落實」的因果鏈,查到目前為止的進度如下,請幫我繼續查證並嚴格區分「你查到的」與「你推論的」。
 
背景:csswg-drafts`#7807` 在 2022-11-16 決議修正 content-visibility:auto 疊加 contain:size 時 last remembered size 記錄失效的問題。我用 Mozilla Bugzilla REST API(quicksearch=7807)與 Chromium 側的公開搜尋/程式碼搜尋,都查不到任何一張票或 commit 標題直接提到 issue 編號 7807。但我在 Mozilla Bugzilla 找到一條相關的內部工程鏈:bug 1807253(2022-12-23 由 Oriol Brufau 開,「Unreliable timing for content-visibility:auto」,target 122 Branch)block 住 bug 1857561/1865994/1867090/1865267(target 120–123,皆 FIXED),後續又有 bug 1880928(2024-02-20 開,Firefox 124 beta 曾標 disabled、125 Branch 才 verified fixed 的迴歸)與目前仍 NEW 的 bug 1940025(2025-01-06 開)。這條鏈沒有一個節點文字上提到 `#7807`。
 
請幫我:
1. 你能不能找到任何一手來源(Chromium Gerrit code review、crbug 內部留言的公開鏡射、Mozilla phabricator revision、或 CSSWG 後續會議紀要)明確把 `#7807` 的決議跟某一次具體的引擎程式碼變更綁在一起?找到請給連結與日期,找不到就直接說找不到。
2. 我的推論是:#7807 的條件修正可能被摻進了 bug 1807253 那一輪為了完全不同理由(ResizeObserver 回呼時機、崩潰斷言)而做的大重構,沒有另開專屬的票。這個推論你能不能用任何額外證據支持或反駁?
3. 查一下 bug 1940025 現在(你查到的當下)的狀態是否還是 NEW,如果已經關閉,告訴我修法說明裡有沒有提到跟 last remembered size 記錄條件或 `#7807` 的關係。
4. 評估「規格決議」與「實作 bug 追蹤」這兩個系統之間完全沒有交叉引用,是不是 CSSWG 生態裡常見的落差,還是這是個特別嚴重的個案。
 
要求:每一點分開回答,查不到的地方明確寫「查不到」,不要用 SEO 內容站當來源,優先用 Bugzilla / Chromium 一手資料。