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)
Core
CSS Parsing and Computation
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.
Comment 1•7 years ago
|
||
This was probably something that emilio made fatal in bug 1380789. Should be easier to see what's going on now.
Comment 2•7 years ago
|
||
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)
Updated•7 years ago
|
Comment 3•7 years ago
|
||
(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 :)
Comment 4•7 years ago
|
||
(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)
Comment 5•7 years ago
|
||
For reference I reproduced the testcase on m-c rev 68046a58f829
Comment 7•7 years ago
|
||
The test case is not related any mouse events, but is related to animation.
Flags: needinfo?(hikezoe)
Comment 8•7 years ago
|
||
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)
Comment 9•7 years ago
|
||
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.
Comment 10•7 years ago
|
||
Filed bug 1382902.
Updated•7 years ago
|
Updated•7 years ago
|
Attachment #8888336 -
Attachment is obsolete: true
Comment 11•7 years ago
|
||
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
Updated•7 years ago
|
status-firefox54:
--- → unaffected
status-firefox55:
--- → unaffected
status-firefox56:
--- → fixed
status-firefox-esr52:
--- → unaffected
Target Milestone: --- → mozilla56
You need to log in
before you can comment on or make changes to this bug.
Description
•