2066182 - Crash in [@ mozilla::dom::ViewTransition::MatchClassList]

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Calixte Denizet (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/a12a810d-d354-41bb-a728-459220260824

Crash Reason:

EXC_BAD_ACCESS / KERN_INVALID_ADDRESS at 0x000000000000004c

Top 10 frames:

0  XUL  PLDHashTable::Search(void const*) const  xpcom/ds/PLDHashTable.cpp:459
1  XUL  mozilla::dom::ViewTransition::MatchClassList(nsAtom*, nsTArray<mozilla::StyleAto...  dom/view-transitions/ViewTransition.cpp:792
2  XUL  style::stylist::Stylist::push_applicable_declarations  servo/components/style/stylist.rs:1748
3  XUL  geckoservo::glue::get_pseudo_style  servo/ports/geckolib/glue.rs:4804
4  XUL  Servo_ResolveStyleLazily  servo/ports/geckolib/glue.rs:7317
5  XUL  mozilla::ServoStyleSet::ResolveStyleLazily(mozilla::dom::Element const&, mozilla...  layout/style/ServoStyleSet.cpp:1326
6  XUL  nsComputedDOMStyle::UpdateCurrentStyleSources(NonCustomCSSPropertyId)  layout/style/nsComputedDOMStyle.cpp:1124
7  XUL  nsComputedDOMStyle::GetPropertyValue(NonCustomCSSPropertyId, nsTSubstring<char>&...  layout/style/nsComputedDOMStyle.cpp:366
8  XUL  mozilla::dom::CSSStyleProperties_Binding::get_display(JSContext*, JS::Handle<JSO...  dom/bindings/CSSStylePropertiesBinding.cpp:928
9  XUL  js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvoke...  js/src/vm/Interpreter.cpp:721

There is 1 crash in nightly 156 with buildid 20260823213825.

This signature is not new: its first report anywhere is in build 20250921092152 (2025-09-21), 336 days before the build above. (A 364-day crash-stats search only reaches 2025-12-12, because Socorro's search index keeps about six months — which is why the signature looks much newer there.)

Clouseau analysis (automated, 72% worth investigating — a calibrated estimate that this is worth someone's time, not that the changeset below caused it). The mechanism below fits the evidence but is not proven end-to-end:

Gecko_MatchViewTransitionClass calls vt->MatchClassList(...) with vt = doc->GetActiveViewTransition() guarded only by a MOZ_ASSERT (a no-op in non-debug nightly builds). When no active ViewTransition exists at the moment a classed named-view-transition pseudo-element selector is matched (e.g. via lazily-resolved getComputedStyle), vt is null and MatchClassList dereferences a null this, crashing inside mNamedElements.Get().

Fault address 0x4c (76) falls inside ViewTransition::mNamedElements's byte range (offset 64, size 40), matching a null-this read of that field; the small, non-poison-shaped address rules out a freed/poisoned-memory (UAF) explanation in favor of a straightforward missing null check.

Starting point — NOT a suspected cause: ca3bdda9fbfd (gh) (bug 1964949) by Boris Chiou.

This changeset did not land in this build's pushlog window, so there is no evidence here that the crash is a recent regression from it; it is named only as the closest thing found on the crash path. If you know where this actually comes from, that correction is the most useful thing you could leave on this bug.

Code references:

• mozilla::dom::ViewTransition::MatchClassList

What the automated skeptic pass checked (its own words — a pass means the check succeeded, which is not always support for the conclusion):

• pass mechanism — Independently re-derived: sole caller of MatchClassList is Gecko_MatchViewTransitionClass, guarded only by a compiled-out MOZ_ASSERT; no null-check found anywhere upstream (Rust matching, lazy-pseudo resolution).
• pass consistency-offset — Fault 0x4c (76) confirmed inside mNamedElements' 64-103 byte span; shape matches null-deref, not poisoned/freed memory.
• pass candidate-timeline — ca3bdda9fbfd (2025-06-14) predates signature first-seen (2025-09-21) by ~3 months, satisfying the causality-direction check.
• pass seed-candidates — Confirmed all 6 provided nightly candidates are noise: no overlap with view-transitions/style-pseudo-matching files.

:boris, can you have a look please?

Filed automatically by Clouseau, which analyses nightly crashes with an LLM. Nothing above was written or checked by a human. Please close it as INVALID if it is wrong — that is useful feedback, not a nuisance.

Comment 1

[Daniel Holbert [:dholbert]]

Marking as depends-on bug 2010608, which shared the same crash signature.

Comment 2

[Daniel Holbert [:dholbert]]

emilio, maybe worth a look from you since you looked at bug 2010608 - do you think this is the same crash that we were investigating there, or something new/different?

The patch we landed over there was a speculative null-check on the return value of mNamedElements.Get(aTransitionName);

But in the crash in comment 0 here, we seem to be crashing with a near-null deref while executing mNamedElements.Get(aTransitionName); (if the backtrace is to be believed).

I wonder if that means the this object itself (i.e. the ViewTransition) is nullptr somehow?

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Yeah, so it seems believable this assert could fire. But I'm curious at what state we are in at that point...

The stacks look interesting:

 2 	XUL 	style::stylist::Stylist::push_applicable_declarations 	servo/components/style/stylist.rs:1748 	cfi
3 	XUL 	style::stylist::Stylist::lazy_pseudo_rules 	servo/components/style/stylist.rs:1582 	inlined
3 	XUL 	style::stylist::Stylist::lazily_compute_pseudo_element_style 	servo/components/style/stylist.rs:1322 	inlined
3 	XUL 	geckoservo::glue::get_pseudo_style 	servo/ports/geckolib/glue.rs:4802 	cfi
4 	XUL 	geckoservo::glue::Servo_ResolveStyleLazily::{{closure}} 	servo/ports/geckolib/glue.rs:7300 	inlined
4 	XUL 	geckoservo::glue::Servo_ResolveStyleLazily::{{closure}} 	servo/ports/geckolib/glue.rs:7333 	inlined
4 	XUL 	core::option::Option<T>::and_then 	/builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/option.rs:1546 	inlined
4 	XUL 	Servo_ResolveStyleLazily 	servo/ports/geckolib/glue.rs:7331 	cfi
5 	XUL 	mozilla::ServoStyleSet::ResolveStyleLazily(mozilla::dom::Element const&, mozilla::PseudoStyleRequest const&, mozilla::StyleRuleInclusion) 	layout/style/ServoStyleSet.cpp:1327 	cfi
6 	XUL 	mozilla::dom::KeyframeEffect::GetTargetComputedStyle(mozilla::dom::KeyframeEffect::Flush) const

Boris, is there any chance to keep a hang on a view transition pseudo animation past the transition?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2066182 - view-transition-class matching shouldn't assume the view transition is active. r=#style,#vt

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/68d8aed86fa7
https://hg.mozilla.org/integration/autoland/rev/1d52c12850b5
view-transition-class matching shouldn't assume the view transition is active. r=firefox-style-system-reviewers,view-transitions-reviewers,dshin,boris

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/62207 for changes under testing/web-platform/tests

Comment 7

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/1d52c12850b5

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot