Closed Bug 1580738 Opened 5 months ago Closed 5 months ago

crash on startup with custom css and homepage

Categories

(Core :: Web Painting, defect, P2)

70 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: jovan.gerodetti, Assigned: mattwoodrow)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

Attached image spinner-busy.svg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

1.) set url as homepage
2.) don't restore previous session
3.) add this css as userChrome.css:

@keyframes rotate-360
{
	0% { transform: rotate(0); }
	100% { transform: rotate(1turn); }
}

.tab-throbber
{
	-moz-context-properties: fill !important;
	fill: currentColor !important;
	background-image: url(spinner-busy.svg) !important;
	margin: 0 !important;
	transform-origin: center !important;
	animation: rotate-360 1.333s linear infinite reverse !important;
	position: static !important;
}

Actual results:

Firefox instantly crashes on launch.

Crash report: https://crash-stats.mozilla.org/report/index/268084e5-195a-4986-8246-f71520190912

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0

Expected results:

Firefox should be able to start without crashing.

Moving to Core | Layout - not sure exactly where to bucket this one.

Status: UNCONFIRMED → NEW
Crash Signature: [@ AssertUniqueItem ]
Component: Untriaged → Layout
Ever confirmed: true
Keywords: crash, regression
Product: Firefox → Core
Component: Layout → Web Painting

Matt, can you take a look? This is a fairly frequent new crash in beta 70.

Flags: needinfo?(matt.woodrow)
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Priority: -- → P2

Our code for handling the layer attribute is pretty weird and sad. Unfortunately we now have renderroot depending on it too, so it'll be hard to clean up too much for now.

We create nsDisplayOwnLayer in response to a layer attribute, on both stacking contexts and a small selection of frame classes. I see no reason why we can't hit both of those cases, and get duplicated items.

I can't reproduce this on OSX, we have the layer attribute, but the element is scrolled so we end up with two frames. The outer is a stacking context, so gets an nsDisplayOwnLayer, the inner is an nsBoxFrame, so also gets one. A lucky escape :)

Attached patch just generates a unique key for all possible callsites and should fix this for now. Maybe we can remove renderroot soon, and possibly the layer attribute entirely with WebRender.

Note that this crash is a Nightly/Beta only assert, so won't affect release (but probably still will render wrong).

Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2064b2f61147
Generate unique per-frame-keys for all nsDisplayOwnLayer call sites. r=mstange
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

No crashes on Nightly since this landed, but it's also getting a bit late in the 70 cycle. Is this something you think we should still uplift, Matt?

It's just a diagnostic assert, so it shouldn't cause any problems in release. I think we're fine to wonfix for now, and let it ride the trains.

Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.