crash when doing javascript animation of 3D transform (css3-3d-transforms)

VERIFIED FIXED in mozilla10



6 years ago
6 years ago


(Reporter: jorge alves, Assigned: mattwoodrow)


Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [inbound][qa!])


(2 attachments, 1 obsolete attachment)



6 years ago
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

6 years ago
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.
Component: Style System (CSS) → Graphics
QA Contact: style-system → thebes
Summary: css transform → crash when doing javascript animation of 3D transform (css3-3d-transforms)
Version: 10 Branch → Trunk
Blocks: 505115

Comment 2

6 years ago
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

6 years ago
                        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

6 years ago
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

6 years ago
Created attachment 566670 [details] [diff] [review]
Use the untransformed overflow area for table bounds
Attachment #566670 - Flags: review?(tnikkel)
Attachment #566670 - Flags: review?(tnikkel) → review+

Comment 6

6 years ago
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

6 years ago
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
Attachment #566690 - Flags: review?(bas.schouten)


6 years ago
Depends on: 691864


6 years ago
Assignee: nobody → matt.woodrow
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).
Attachment #566690 - Flags: review?(bas.schouten) → review+

Comment 9

6 years ago
Created attachment 566703 [details] [diff] [review]
Check return values in ContainerLayerD3D10

Fixed review comments, carrying forward r=Bas
Attachment #566690 - Attachment is obsolete: true
Attachment #566703 - Flags: review+

Comment 10

6 years ago
Whiteboard: [inbound]
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 12

6 years ago
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.
Whiteboard: [inbound] → [inbound][qa!]
You need to log in before you can comment on or make changes to this bug.