Closed Bug 1339097 Opened 3 years ago Closed 3 years ago

Crash in mozilla::PresShell::Paint

Categories

(Core :: Web Painting, defect, critical)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox52 --- unaffected
firefox53 --- unaffected
firefox54 --- fixed

People

(Reporter: marcia, Assigned: kats)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-dadb16ad-c025-44fc-9426-19a8e2170213.
=============================================================

Seen while looking at nightly crash stats - crashes started with 20170211030205: http://bit.ly/2lbNn78.

Possible regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=25a94c1047e793ef096d8556fa3c26dd72bd37d7&tochange=855e6b2f6199189f37cea093cbdd1735e297e8aa. Maybe Bug 1331294? ni on :heycam
Flags: needinfo?(cam)
I doubt it is Cameron's bug. More likely its the graphics branch merge to m-c.
Flags: needinfo?(cam) → needinfo?(bugmail)
It shouldn't be the graphics branch merge. 99% of that code isn't even activated unless Firefox is built with --enable-webrender, and that's not yet the case on nightly builds. I'm pretty sure we didn't touch anything in the crash stack. Putting needinfo back to heycam but I'm doubtful it's from his bug either.
Flags: needinfo?(bugmail) → needinfo?(cam)
Whatever caused this is unlikely to have changed code in the crash stack as the layer manager on a widget (the crash is on a null layer manager from the widget) is set up (hopefully) long before anything in this stack. I didn't see anything else likely on a quick scan of the pushlog.
Hm. I misread the code the first time, sorry. I guess this might be a regression from https://hg.mozilla.org/projects/graphics/rev/b7619d5557e0, I can take a look.
Assignee: nobody → bugmail
Flags: needinfo?(cam)
So this is almost certainly a result of PuppetWidget::GetLayerManager returning null if it doesn't have a mTabChild. I'd really like to know what kind of scenario results in the creation and painting of a PuppetWidget which doesn't have an associated TabChild, but we don't have STR and none of the crashes have any comments.

So for now I think it's better to just fall back to using the gfxVars::UseWebRender if we don't have a TabChild. We already basically concluded that trying to mix compositors is not really going to go well. We might want to get rid of the CompositorOptions entirely but there might still be some value in keeping it for now. I'm working on a patch.
Comment on attachment 8837250 [details]
Bug 1339097 - Allow PuppetWidget::GetLayerManager to return a layer manager even if it doesn't have a tabchild.

https://reviewboard.mozilla.org/r/112420/#review113818
Attachment #8837250 - Flags: review?(dvander) → review+
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ab41a32432a3
Allow PuppetWidget::GetLayerManager to return a layer manager even if it doesn't have a tabchild. r=dvander
https://hg.mozilla.org/mozilla-central/rev/ab41a32432a3
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.