Closed Bug 1505934 Opened 2 years ago Closed 2 years ago

RenderTask::new_mask crash on


(Core :: Graphics: WebRender, defect, P2)




Tracking Status
firefox-esr60 --- unaffected
firefox64 --- disabled
firefox65 --- disabled
firefox66 --- verified


(Reporter: jrmuizel, Assigned: kvark)


(Blocks 2 open bugs)


(Keywords: crash, regression)

Crash Data


(2 files)

No description provided.
Load the page in the title and scroll down.

This is the crash report I get:
Priority: -- → P2
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ]
Assignee: nobody → dglastonbury
dupe of 1513062 ?

latest crash:
Flags: needinfo?(bobbyholley)
Duplicate of this bug: 1513062
Same crash on Both have the same regression range.
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ]
Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(bobbyholley)
Keywords: crash, regression
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
Thanks for noticing the dupe :)
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ]
Severity: normal → critical
See Also: → 1515932
I've been investigating this assert and it's related to perspective applied to an image with scaling.

Reduced testcase
It might required clicking in the frame to trigger the assert. It doesn't always happen immediately.

I don't understand the behavior of elements with perspective applied and how pictures interact, but we shouldn't render at 90000x90000 to scale back down to 900x900. :emilio, :mattwoodrow can either of you help?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(emilio)

The testcase appears to roughly be:


With the addition of perspective, to make the transforms more difficult.

The presence of the perspective means that it's hard to combine the two transforms, as we'd also have to transform the rounded rect and turn it into an arbitrary mask.

I guess that's one possible option, otherwise we probably just need to do the intermediate surface at a lower resolution (scale down to fit within a reasonable size).

Flags: needinfo?(matt.woodrow)

The test also has opacity, so the path that hits the assert in WR is setting up the processing of the PictureCompositeMode::Filter(Opacity(..)) at

It would be better that someone who understands picture caching to implement the correct fix for this, instead of me, so I'm unassigning myself so it can be picked up by another.

Assignee: dglastonbury → nobody
Assignee: nobody → dmalyshau

There is a combination of factors in play here:

  1. a filter forces some compositor mode, which makes WR want to produce a surface for the stacking context
  2. a perspective transformation makes WR to choose the local space for rasterization
  3. a very large clip mask as an example of a render task

Produced test case (included in the crashtests with the PR):

  body {
      background-color: limegreen;
  .A {
      transform: scale(0.01) perspective(1000px);
      transform-origin: 0% 0%;
      filter: grayscale(40%);
  .B {
      background-color: black;
      width: 10000px;
      height: 5000px;
      border-radius: 2000px;
  <div class="A">
      <div class = "B"/>
Flags: needinfo?(emilio)

I got this issue today.

[Reproduce Steps]

  1. Restart Firefox 65.0b10
  2. Go to
  3. Then Firefox 65.0b10 will be crashed sometimes.
Duplicate of this bug: 1515932
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ] → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ] [@ webrender::renderer::Renderer…
Pushed by
WR: Don't establish a raster root in pictures with sufficiently large local bounds r=gw
re-open of D16335, which got backed out due to Wrench test failing.
The test was failing because of different AA on a plane-splitting case, which isn't guaranteed anyway.
This revision updates the test.
Pushed by
WR: Don't establish a raster root in pictures with sufficiently large local bounds (take 2) r=jrmuizel

Re-landing now with the Wrench test adjusted: it's purpose is to check the ordering of planes in preserve-3d context. We don't guarantee AA there, so the change in result is acceptable.

Flags: needinfo?(dmalyshau)
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

bug 1515932 was not a dupe. Removing signature.

Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ] [@ webrender::renderer::Renderer… → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ]

I have managed to crash Fx 65.0a1 buildID: 20181108220756 using the page in the title only on macOS 10.14. On Ubuntu 16.04 Fx only crashed with the link from comment 6. On Windows Fx didn't crash at all, 'best' result being the window becoming unresponsive for 2-3 seconds then returning to normal.

The issue is verified fixed using Fx 66.0b14 on macOS 10.14, Ubuntu 16.04 and Windows 10. The issues mentioned above no longer occur on the latest beta with gfx.webrender.all set to true.

You need to log in before you can comment on or make changes to this bug.