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".

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?

(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

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