Requires: layout.css.individual-transform.enabled=true

Assertion failure: !layerClip || !aLayer->Combines3DTransformWithAncestors() (The layer with a clip should not participate a 3D rendering context), at src/gfx/layers/composite/LayerManagerComposite.cpp:329

#0 mozilla::layers::LayerManagerComposite::PostProcessLayers(mozilla::layers::Layer*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits>&, mozilla::gfx::IntRegionTyped<mozilla::LayerPixel>&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::RenderTargetPixel> > const&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel> > const&, bool) src/gfx/layers/composite/LayerManagerComposite.cpp:327:3
#1 mozilla::layers::LayerManagerComposite::PostProcessLayers(mozilla::layers::Layer*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits>&, mozilla::gfx::IntRegionTyped<mozilla::LayerPixel>&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::RenderTargetPixel> > const&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel> > const&, bool) src/gfx/layers/composite/LayerManagerComposite.cpp:392:7
#2 mozilla::layers::LayerManagerComposite::PostProcessLayers(mozilla::layers::Layer*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits>&, mozilla::gfx::IntRegionTyped<mozilla::LayerPixel>&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::RenderTargetPixel> > const&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel> > const&, bool) src/gfx/layers/composite/LayerManagerComposite.cpp:392:7
#3 mozilla::layers::LayerManagerComposite::PostProcessLayers(mozilla::layers::Layer*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits>&, mozilla::gfx::IntRegionTyped<mozilla::LayerPixel>&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::RenderTargetPixel> > const&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel> > const&, bool) src/gfx/layers/composite/LayerManagerComposite.cpp:392:7
#4 mozilla::layers::LayerManagerComposite::PostProcessLayers(mozilla::layers::Layer*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits>&, mozilla::gfx::IntRegionTyped<mozilla::LayerPixel>&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::RenderTargetPixel> > const&, mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel> > const&, bool) src/gfx/layers/composite/LayerManagerComposite.cpp:392:7
#5 mozilla::layers::LayerManagerComposite::PostProcessLayers(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits>&) src/gfx/layers/composite/LayerManagerComposite.cpp:297:3
#6 mozilla::layers::LayerManagerComposite::UpdateAndRender() src/gfx/layers/composite/LayerManagerComposite.cpp:546:3
#7 mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const&, mozilla::layers::LayerManager::EndTransactionFlags) src/gfx/layers/composite/LayerManagerComposite.cpp:521:5
#8 mozilla::layers::CompositorBridgeParent::CompositeToTarget(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*) src/gfx/layers/ipc/CompositorBridgeParent.cpp:1012:18
#9 mozilla::layers::CompositorVsyncScheduler::ForceComposeToTarget(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*) src/gfx/layers/ipc/CompositorVsyncScheduler.cpp:274:25
#10 mozilla::layers::CompositorBridgeParent::ForceComposeToTarget(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*) src/gfx/layers/ipc/CompositorBridgeParent.cpp:1083:25
#11 mozilla::layers::CompositorBridgeParent::RecvFlushRendering() src/gfx/layers/ipc/CompositorBridgeParent.cpp:567:5
#12 mozilla::layers::PCompositorBridgeParent::OnMessageReceived(IPC::Message const&, IPC::Message*&) src/obj-firefox/ipc/ipdl/PCompositorBridgeParent.cpp:1716:70
#13 mozilla::ipc::MessageChannel::DispatchSyncMessage(IPC::Message const&, IPC::Message*&) src/ipc/glue/MessageChannel.cpp:2121:21
#14 mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) src/ipc/glue/MessageChannel.cpp:2074:9
#15 mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) src/ipc/glue/MessageChannel.cpp:1937:3
#16 mozilla::ipc::MessageChannel::MessageTask::Run() src/ipc/glue/MessageChannel.cpp:1968:13
#17 MessageLoop::RunTask(already_AddRefed<nsIRunnable>) src/ipc/chromium/src/base/message_loop.cc:442:9
#18 MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask&&) src/ipc/chromium/src/base/message_loop.cc:450:5
#19 MessageLoop::DoWork() src/ipc/chromium/src/base/message_loop.cc:523:13
#20 base::MessagePumpDefault::Run(base::MessagePump::Delegate*) src/ipc/chromium/src/base/message_pump_default.cc:35:31
#21 MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:315:10
#22 MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:290:3
#23 base::Thread::ThreadMain() src/ipc/chromium/src/base/thread.cc:192:16
#24 ThreadFunc(void*) src/ipc/chromium/src/base/platform_thread_posix.cc:40:13

The priority flag is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

Not sure the root cause. I replaced rotate: -1deg 48 0 0 with transform: rotate3d(48, 0, 0, -1deg), and the assertion would be gone. Looks like individual transforms will set CONTENT_EXTEND_3D_CONTEXT in this testcase. Besides, I thought both transforms call BuildLayer(), but after checking the log, I noticed transform: rotate3d(48, 0, 0, -1deg) doesn't call nsDisplayTransform::BuildLayer(), so didn't set this flag? Don't understand actually. May need to know why we set CONTENT_EXTEND_3D_CONTEXT only for individual transform, i.e. rotate property.

I think the reason we don't call BuildLayer for the transform: rotate3D case is because we return LAYER_INACTIVE for nsDisplayTransform::GetLayerState, and then we can take an optimized path to skip the layer entirely.

The assertion is there because we can't (due to the spec, and implementation) have a clip between a frame that creates a 3d context, and a frame that is combined into it.

I would expect in this case that the preserve-3d frame (the table) and the transformed frame (the th) to not attempt to form a 3d context, since there are other frames between them (the row group, and the row frames).

In that case I'd expect an nsDisplayTransform with CONTENT_EXTEND_3D_CONTEXT created for the table, an nsDisplayTransform as a 'separator', and then the nsDisplayTransform for the rotation. The separator should make aLayer->Combines3DTransformWithAncestors return false for the rotation.

It'd be worth dumping out the display lists and Layer trees for both versions here to see where they differ.

(In reply to Matt Woodrow (:mattwoodrow) from comment #3)

It'd be worth dumping out the display lists and Layer trees for both versions here to see where they differ.

Cool. Thanks for this explanation. Let me dump the display lists and layer trees for more information. :)

(In reply to Boris Chiou [:boris] from comment #2)

Not sure the root cause. I replaced rotate: -1deg 48 0 0 with transform: rotate3d(48, 0, 0, -1deg)...

My fault. I tested transform: rotate3d(48, 0, 0, -1deg) with some typos, so didn't get assertions. Actually, in both cases, I saw the same assertion. In other words, this is a bug for both rotate: -1deg 48 0 0; (with layout.css.individual-transform.enable=true) and transform: rotate3d(48, 0, 0, -1deg); (with layout.css.individual-transform.enable=false).

Adding birtles and hiro to cc, since they understand how transforms and tables work together better than I do.

I can't reproduce the assertion locally at all, I don't know why. Anyways, as far as I can tell the Combines3DTransformWithAncestors call for |aFrame| should be for |styleFrame| there. (Or we should use Combines3DTransformWithAncestors(const nsStyleDisplay*) with styleFrame->StyleDisplay() for optimizations?)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #7)

I can't reproduce the assertion locally at all, I don't know why. Anyways, as far as I can tell the Combines3DTransformWithAncestors call for |aFrame| should be for |styleFrame| there. (Or we should use Combines3DTransformWithAncestors(const nsStyleDisplay*) with styleFrame->StyleDisplay() for optimizations?)

I always find it hard to remember, but I think that should actually use the primary frame. The transform styles are inherited from the style frame to the primary frame anyway, and IsCSSTransformed (as called by Combines3DTransformWithAncestors) will only return true for the primary frame. So I think it might actually be correct.

This shouldn't block the ship of individual transform.

I think the assertion no longer happens (since bug 1567108?)

Is it worth landing the testcase as a crashtest still?

Depends on D47566

Yes, it's definitely worth adding. thanks for the notice.

https://hg.mozilla.org/mozilla-central/rev/c99e076208bb

Bugbug thinks this bug is a regression, but please revert this change in case of error.