1443926 - Crash in core::option::expect_failed | style::style_resolver::StyleResolverForElement<T>::match_primary<T>

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-9deb2823-ae7d-41e2-9983-4fa8c0180307.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll std::panicking::rust_panic_with_hook src/libstd/panicking.rs:583
1 xul.dll std::panicking::begin_panic<alloc::string::String> src/libstd/panicking.rs:538
2 xul.dll std::panicking::begin_panic_fmt src/libstd/panicking.rs:522
3 xul.dll core::panicking::panic_fmt src/libcore/panicking.rs:71
4 xul.dll core::option::expect_failed src/libcore/option.rs:891
5 xul.dll style::style_resolver::StyleResolverForElement<style::gecko::wrapper::GeckoElement>::match_primary<style::gecko::wrapper::GeckoElement> servo/components/style/style_resolver.rs:444
6 xul.dll style::style_resolver::StyleResolverForElement<style::gecko::wrapper::GeckoElement>::resolve_style<style::gecko::wrapper::GeckoElement> servo/components/style/style_resolver.rs:224
7 xul.dll geckoservo::glue::Servo_ResolveStyleLazily servo/ports/geckolib/glue.rs:3743
8 xul.dll mozilla::ServoStyleSet::ResolveStyleLazilyInternal layout/style/ServoStyleSet.cpp:1454
9 xul.dll mozilla::ServoStyleSet::ResolveStyleLazily layout/style/ServoStyleSet.cpp:648

=============================================================

reports with this signature are newly showing up in firefox 59 & 60 with MOZ_CRASH Reason "Trying to collect rules for a detached pseudo-element".

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Hmm, is there any repro url? I couldn't repro in any of those.

"Trying to collect rules for a detached pseudo-element" usually means that something in the DOM is messed up. This is from a GetComputedStyle call in a content process so that means that either somehow we're exposing a pseudo-element to content, or that https://searchfox.org/mozilla-central/rev/33cc9e0331da8d9ff3750f1e68d72d61201176cb/layout/style/ServoStyleSet.cpp#1439 is wrong, but given we clear that property on nsXMLElement::UnbindFromTree, that seems unlikely.

Jryans, is there any chance that devtools can keep a reference to a pseudo-element after its layout tree is destroyed, and then you call getComputedStyle on it?

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #1)
> Jryans, is there any chance that devtools can keep a reference to a
> pseudo-element after its layout tree is destroyed, and then you call
> getComputedStyle on it?

That does sound possible to me, yes.  The inspector uses nsIDeepTreeWalker to access nodes in the document, and this includes handing out nodes for ::before / ::after.

There are various possible paths where we might later call `getComputedStyle` on such a thing.  We have a centralized helper[1] that attempt to first check that the node is still alive and attached in various ways before proceeding.

However, I did notice at least one[2] call to the bare method without checks in the animation tab of the inspector.  So, it's possible using this tool with such a pseudo-element could trigger what you describe.  It's hard to be sure without a test case though.

[1]: https://searchfox.org/mozilla-central/rev/33cc9e0331da8d9ff3750f1e68d72d61201176cb/devtools/server/css-logic.js#671
[2]: https://searchfox.org/mozilla-central/rev/588d8120aa11738657da93e09a03378bcd1ba8ec/devtools/server/actors/animation.js#280

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Filed bug 1444241 for the animation inspector code path mentioned above.  Unsure if it's related to this crash.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.