When I tried the steps mentioned in bug 1379218 comment 7, I got this assertion. The full stack is: thread '<unnamed>' panicked at 'Resolving style on element without current styles', .\servo\ports\geckolib\glue.rs:2783 stack backtrace: 0: std::sys_common::backtrace::_print at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94 1: std::panicking::default_hook::{{closure}} at C:\projects\rust\src\libstd\panicking.rs:354 2: std::panicking::default_hook at C:\projects\rust\src\libstd\panicking.rs:371 3: std::panicking::rust_panic_with_hook at C:\projects\rust\src\libstd\panicking.rs:549 4: std::panicking::begin_panic<&str> at C:\projects\rust\src\libstd\panicking.rs:511 5: geckoservo::glue::Servo_ResolveStyle at .\servo\ports\geckolib\glue.rs:2783 6: mozilla::ServoStyleSet::ResolveServoStyle at .\layout\style\servostyleset.cpp:1177 7: mozilla::ServoRestyleManager::ProcessPostTraversal at .\layout\base\servorestylemanager.cpp:553 And it seems this is because data.has_invalidations() returns true. It might be related to bug 1378064.

This was probably something that emilio made fatal in bug 1380789. Should be easier to see what's going on now.

This is slightly different starting from frame 8, but I'm hoping it's the same issue. thread '<unnamed>' panicked at 'Resolving style on element without current styles', /home/worker/workspace/build/src/servo/ports/geckolib/glue.rs:2805 stack backtrace: 0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace 1: std::sys_common::backtrace::_print 2: std::panicking::default_hook::{{closure}} 3: std::panicking::default_hook 4: std::panicking::rust_panic_with_hook 5: std::panicking::begin_panic 6: Servo_ResolveStyle 7: mozilla::ServoStyleSet::ResolveServoStyle(mozilla::dom::Element*, mozilla::TraversalRestyleBehavior) 8: mozilla::ServoStyleSet::GetContext(nsIContent*, mozilla::ServoStyleContext*, nsIAtom*, mozilla::CSSPseudoElementType, mozilla::LazyComputeBehavior) 9: mozilla::ServoStyleSet::ResolveStyleFor(mozilla::dom::Element*, mozilla::ServoStyleContext*, mozilla::LazyComputeBehavior) 10: nsCSSFrameConstructor::ResolveStyleContext(nsStyleContext*, nsIContent*, nsFrameConstructorState*, mozilla::dom::Element*) 11: nsCSSFrameConstructor::ResolveStyleContext(nsIFrame*, nsIContent*, nsIContent*, nsFrameConstructorState*) 12: nsCSSFrameConstructor::ResolveStyleContext(nsCSSFrameConstructor::InsertionPoint const&, nsIContent*, nsFrameConstructorState*) 13: nsCSSFrameConstructor::AddFrameConstructionItems(nsFrameConstructorState&, nsIContent*, bool, nsCSSFrameConstructor::InsertionPoint const&, nsCSSFrameConstructor::FrameConstructionItemList&) 14: nsCSSFrameConstructor::ContentAppended(nsIContent*, nsIContent*, bool, bool, TreeMatchContext*) 15: mozilla::PresShell::ContentAppended(nsIDocument*, nsIContent*, nsIContent*, int)

(In reply to Jesse Schwartzentruber (:truber) from comment #2) > Created attachment 8888336 [details] > testcase.html > > This is slightly different starting from frame 8, but I'm hoping it's the > same issue. The test-case doesn't crash on latest's nightly, but that's a nasty enough test-case that I think it's worth checking it in :)

(In reply to Emilio Cobos Álvarez [:emilio] from comment #3) > (In reply to Jesse Schwartzentruber (:truber) from comment #2) > > Created attachment 8888336 [details] > > testcase.html > > > > This is slightly different starting from frame 8, but I'm hoping it's the > > same issue. > > The test-case doesn't crash on latest's nightly, but that's a nasty enough > test-case that I think it's worth checking it in :) Oh, well, I forgot that we disabled that assertion on nightly... Yeah, then presumably this is the same issue, hiro had a patch to fix the assertion IIRC (not sure it landed)

For reference I reproduced the testcase on m-c rev 68046a58f829

Cameron, perhaps this is the same as bug 1382568?

The test case is not related any mouse events, but is related to animation.

Animation-only restyle is skipped. This is a case that we need to run animation-only restyle right after normal initial restyle.

Or just ignore the case in the debug_assert!(). Anyway, the test case in comment 2 is slightly from 1382568, and I think it's harmless because the skipped animation restyle will be processed in the next tick anyway. Also the test case fails on debug_assert!(element.has_current_styles_for_traversal(&*data, flags), whereas bug 1382568 fails on assert!(data.has_styles()). I will open a new bug for the test case in comment 2.

Filed bug 1382902.

The panic in the original report in comment 0 has been degraded and caused by a different issue from comment 2. And the cause has been fixed by bug 1371450 or bug 1371450. The test case in comment 2 has been tracked in bug 1382902.