Problem
The inbox sidebar's onLayout path hardcoded is_warm: false while the focus path hardcoded true. Since endSpan deletes the tracked span, whichever signal arrived first won, so the attribute reported event ordering rather than whether the screen had already been mounted. On web the layout path always wins: a blurred tab pane gets display: none and onLayout is driven by ResizeObserver, so returning to the tab fires it again on a node that was never unmounted — every warm return was therefore reported as cold. Native was unaffected because react-freeze keeps the layout, onLayout does not fire again, and the focus path correctly reports warm. The skew is visible in 14 days of data (n=225,332): warm share of 0.12% on web desktop wide against 62.80% on web desktop narrow and 44.58% on native, flipping on wide_layout alone.
Solution
Track repeat layouts in useInboxTabSpanLifecycle by reading hasHadFirstLayout into isRepeatLayout before setting it, then pass that value as ATTRIBUTE_IS_WARM instead of a hardcoded false. The first layout on an instance is cold and any later layout is a warm re-visit, and because both end paths now read the same ref the reported value no longer depends on which one fires first. Verified in a wide browser window: a cold first mount reports is_warm: false at 681ms while three returns on the same DOM node report is_warm: true at 151ms, 140ms and 154ms. Two new tests cover the repeat-layout case and the agreement between the two end paths.
Note for whoever reads the resulting dashboards: the is_warm:false cohort will shrink and its p50/p95 will rise, because the returns leaving that cohort are four to six times cheaper than a real mount. That is the true first-mount cost becoming visible and should be re-baselined, not read as a regression. Warm durations are also not comparable across layouts (roughly 20ms narrow vs 150ms wide), which is what wide_layout separates.
PR
#98022
Issue Owner
Current Issue Owner: @BartekObudzinski
Problem
The inbox sidebar's
onLayoutpath hardcodedis_warm: falsewhile the focus path hardcodedtrue. SinceendSpandeletes the tracked span, whichever signal arrived first won, so the attribute reported event ordering rather than whether the screen had already been mounted. On web the layout path always wins: a blurred tab pane getsdisplay: noneandonLayoutis driven by ResizeObserver, so returning to the tab fires it again on a node that was never unmounted — every warm return was therefore reported as cold. Native was unaffected because react-freeze keeps the layout,onLayoutdoes not fire again, and the focus path correctly reports warm. The skew is visible in 14 days of data (n=225,332): warm share of 0.12% on web desktop wide against 62.80% on web desktop narrow and 44.58% on native, flipping onwide_layoutalone.Solution
Track repeat layouts in
useInboxTabSpanLifecycleby readinghasHadFirstLayoutintoisRepeatLayoutbefore setting it, then pass that value asATTRIBUTE_IS_WARMinstead of a hardcodedfalse. The first layout on an instance is cold and any later layout is a warm re-visit, and because both end paths now read the same ref the reported value no longer depends on which one fires first. Verified in a wide browser window: a cold first mount reportsis_warm: falseat 681ms while three returns on the same DOM node reportis_warm: trueat 151ms, 140ms and 154ms. Two new tests cover the repeat-layout case and the agreement between the two end paths.Note for whoever reads the resulting dashboards: the
is_warm:falsecohort will shrink and its p50/p95 will rise, because the returns leaving that cohort are four to six times cheaper than a real mount. That is the true first-mount cost becoming visible and should be re-baselined, not read as a regression. Warm durations are also not comparable across layouts (roughly 20ms narrow vs 150ms wide), which is whatwide_layoutseparates.PR
#98022
Issue Owner
Current Issue Owner: @BartekObudzinski