Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
P1
normal
5 days ago
2 hours ago

People

(Reporter: xidorn, Unassigned, NeedInfo)

Tracking

(Blocks: 2 bugs, {assertion, crash})

Trunk
assertion, crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

5 days ago
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
Created attachment 8888336 [details]
testcase.html

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.
Filed bug 1382902.
No longer blocks: 1172704, 1333171, 1334591
Flags: in-testsuite?
Keywords: testcase
Attachment #8888336 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.