Closed Bug 1381357 Opened 7 years ago Closed 7 years ago

stylo: thread '<unnamed>' panicked at 'Resolving style on element without current styles'

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- fixed

People

(Reporter: xidorn, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash)

Attachments

(1 obsolete file)

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.
Keywords: crash
Priority: -- → P1
Attached file testcase.html (obsolete) —
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)
Flags: in-testsuite?
Keywords: assertion, testcase
(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?
Flags: needinfo?(cam)
The test case is not related any mouse events, but is related to animation.
Flags: needinfo?(hikezoe)
Animation-only restyle is skipped. This is a case that we need to run animation-only restyle right after normal initial restyle.
Flags: needinfo?(hikezoe)
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.
No longer blocks: stylo-fuzzing
Flags: in-testsuite?
Keywords: testcase
Attachment #8888336 - Attachment is obsolete: true
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(cam)
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: