Last Comment Bug 692968 - crash when doing javascript animation of 3D transform (css3-3d-transforms)
: crash when doing javascript animation of 3D transform (css3-3d-transforms)
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86_64 Windows 7
-- normal (vote)
: mozilla10
Assigned To: Matt Woodrow (:mattwoodrow)
: Milan Sreckovic [:milan]
Depends on: 691864
Blocks: 505115
  Show dependency treegraph
Reported: 2011-10-07 15:32 PDT by jorge alves
Modified: 2011-12-15 08:02 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Use the untransformed overflow area for table bounds (907 bytes, patch)
2011-10-12 16:27 PDT, Matt Woodrow (:mattwoodrow)
tnikkel: review+
Details | Diff | Splinter Review
Check return values in ContainerLayerOGL (1.64 KB, patch)
2011-10-12 16:59 PDT, Matt Woodrow (:mattwoodrow)
bas: review+
Details | Diff | Splinter Review
Check return values in ContainerLayerD3D10 (1.69 KB, patch)
2011-10-12 17:39 PDT, Matt Woodrow (:mattwoodrow)
matt.woodrow: review+
Details | Diff | Splinter Review

Description User image jorge alves 2011-10-07 15:32:03 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111007 Firefox/10.0a1
Build ID: 20111007031227

Steps to reproduce:

1. go to
2. type the following one-line script into the web console:

window.setInterval("if(window.angle === undefined) window.angle = 0; document.getElementById('transform-property') = 'perspective(600px) rotateY(' + window.angle + 'deg)'; ++window.angle;",100)

Actual results:

the table rotated for a while and then it crashed

Expected results:

it should keep rotating forever
Comment 1 User image jorge alves 2011-10-07 15:36:26 PDT
Crash report:

Now the funny part: it doesn't happen in safe mode or with a clean profile. Disabling all add-ons didn't make a difference.

During testing I also noticed that the rotated table is being clipped at (very roughly) 60~120 degrees, but with a clean profile it doesn't happen.
Comment 2 User image Matt Woodrow (:mattwoodrow) 2011-10-11 22:09:40 PDT
I can't reproduce this on mozilla-central, but I do get 'failed to create texture' assertions from ThebesLayerD3D10.cpp:416. aSize = {10485, 6401 }, and other crazy sizes that explain why we can't create textures.

This is most likely because of bug 689416, and we no longer create intermediate surfaces in the container.

Anyway, the bug still presumably exists, because we don't check the return value when we create textures in ContainerLayerOGL.cpp.

We could also probably clip the created texture size to inverse transformed bounds of the current clip and stop this failing.

I'm still looking into why the visible region is so big in the first place
Comment 3 User image Matt Woodrow (:mattwoodrow) 2011-10-12 02:38:58 PDT
                        nsDisplayTransform 1136E308(Table(table)(50)) (52820,-31
                            Background 1136E308(Table(table)(50)) (4260,29082,78
360,9984)(0,0,0,0) opaque uniform
                            TableBorderBackground 1136E308(Table(table)(50)) (-4

The offending element appears to be this TableBorderBackground.
Comment 4 User image Matt Woodrow (:mattwoodrow) 2011-10-12 15:14:14 PDT
I'm a little confused here.

nsDisplayTransform::BuildLayer() calls FrameLayerBuilder::BuildContainerLayerFor.

This sets the visible region of the container contents, which should be in untransformed coordinates, right?

The visible region is determined by the bounds of the children, and in the case of TableBorderBackground, the visual overflow rect. Since this is the same frame, it is transformed, and the visual overflow rect is in transformed coordinate space.

The frame width is only 78360, but the overflow rect width is 596308 because of the transformation.

We then try allocate a ThebesLayer texture of this size, and fail.
Comment 5 User image Matt Woodrow (:mattwoodrow) 2011-10-12 16:27:06 PDT
Created attachment 566670 [details] [diff] [review]
Use the untransformed overflow area for table bounds
Comment 6 User image jorge alves 2011-10-12 16:51:20 PDT
I must say that I can't reproduce the crash since at least monday's nightly. Maybe it was fixed in bug 689416 like you mentioned in comment #2 ?

After landing I'll verify if the clipping differences are still present.
Comment 7 User image Matt Woodrow (:mattwoodrow) 2011-10-12 16:59:29 PDT
Created attachment 566690 [details] [diff] [review]
Check return values in ContainerLayerOGL

This fixes the crash/flickering but the text still dissapears at some angles.

In these cases we're not creating the Text display items, so I believe this problem is the same as bug 691864
Comment 8 User image Bas Schouten (:bas.schouten) 2011-10-12 17:14:25 PDT
Comment on attachment 566690 [details] [diff] [review]
Check return values in ContainerLayerOGL

Review of attachment 566690 [details] [diff] [review]:

Make sure you say ContainerLayerD3D10 in your commit message :)

::: gfx/layers/d3d10/ContainerLayerD3D10.cpp
@@ +204,5 @@
> +    HRESULT hr;
> +    hr = device()->CreateTexture2D(&desc, NULL, getter_AddRefs(renderTexture));
> +
> +    if (FAILED(hr)) {
> +      NS_WARNING("Failed to create new texture for ContainerLayerD3D10!");

Use LayerManagerD3D10::ReportFailure here.

@@ +210,5 @@
> +    }
> +
> +    hr = device()->CreateRenderTargetView(renderTexture, NULL, getter_AddRefs(rtView));
> +
> +    if (FAILED(hr)) {

Let's replace this by an NS_ASSERTION(SUCCEEDED(hr).
Comment 9 User image Matt Woodrow (:mattwoodrow) 2011-10-12 17:39:23 PDT
Created attachment 566703 [details] [diff] [review]
Check return values in ContainerLayerD3D10

Fixed review comments, carrying forward r=Bas
Comment 12 User image Ioana (away) 2011-12-15 08:02:13 PST
Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111214 Firefox/10.0a2
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111215 Firefox/11.0a1

The table kept rotating on all Fx builds. No crashes occured.

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