Seen on current trunk during monkey testing. I/Gecko (10172): [Child 10172] WARNING: Transparent content with displayports can be expensive.: file /Volumes/mac/moz/ib2g/layout/base/nsDisplayList.cpp, line 1576 F/MOZ_Assert(10172): Assertion failure: mSetActiveTask == nullptr, at /Volumes/mac/moz/ib2g/gfx/layers/apz/util/ActiveElementManager.cpp:91

Can you enable the AEM_LOG at the top of the ActiveElementManager.cpp and attach the logcat?

Not sure if this is related. Before, I had a child crash but now I noticed a crash in the parent: I/Gecko ( 9149): --DOCSHELL 0xafc4a000 == 1 [pid = 9149] [id = 2] I/Gecko ( 9149): [Child 9149] WARNING: NS_ENSURE_TRUE(mDocShell) failed: file /Volumes/mac/moz/ib2g/embedding/browser/nsWebBrowser.cpp, line 363 I/Gecko ( 9149): [Child 9149] WARNING: NS_ENSURE_TRUE(domWindow) failed: file /Volumes/mac/moz/ib2g/embedding/browser/nsDocShellTreeOwner.cpp, line 83 I/Gecko ( 8337): AEM: Touch end event, aWasClick: 0 I/Gecko ( 8337): AEM: Cancelling task 0x0 I/Gecko ( 8337): AEM: Resetting active from 0xac372100 I/Gecko ( 8337): AEM: Found root 0xac0c3e10, making active I/Gecko ( 8337): AEM: Setting active 0xac0c3e10 I/Gecko ( 8337): AEM: Element 0xac0c3e10 doesn't use active styles F/MOZ_CRASH( 8337): Hit MOZ_CRASH() at /Volumes/mac/moz/ib2g/ipc/glue/MessageLink.cpp:187 F/libc ( 8337): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 8337 (b2g)

Saw this today on aries when pressing the refresh button in the email app at a high frequency.

The relevant bit of the log is this: I/Gecko (12131): AEM: Setting target element to 0xafb8e0b0 I/Gecko (12131): AEM: Touch start, aCanBePan: 1 I/Gecko (12131): AEM: Scheduling mSetActiveTask 0xaf168820 I/Gecko (12131): AEM: Touch end, clearing pan state I/Gecko (12131): AEM: Touch start, aCanBePan: 1 F/MOZ_Assert(12131): Assertion failure: mSetActiveTask == nullptr, at /Volumes/mac/moz/ib2g/gfx/layers/apz/util/ActiveElementManager.cpp:91 The target element get set, and then we get the HandleTouchStart call. This schedules the activation task. Then we get a HandleTouchEnd followed by another HandleTouchStart which tries to schedule a new task, and causes the assertion. The HandleTouchEndEvent function (not the same as HandleTouchEnd) appears to not be getting called in between. Both HandleTouchStart and HandleTouchEnd are triggered by state change notifications from APZ, and HandleTouchEndEvent is triggered by the arrival of the touch-end event. However I think these should all be happening in order, since the path they take from the APZ to the content process is the same (compositor thread -> root process main thread -> child process main thread). I don't see how the HandleTouchStart for the second touch-down can arrive before the HandleTouchEndEvent for the first touch.

Oh. The touch-end event goes from the compositor thread -> root process main thread via NS_DispatchToMainThread [1] whereas the state-change notification goes from the compositor thread -> root process main thread via the chromium message loop [2]. [2] is probably faster than [1], resulting in the out-of-order arrival in the child process. [1] https://hg.mozilla.org/mozilla-central/file/5b4c240e1a36/widget/gonk/nsWindow.cpp#l273 [2] https://hg.mozilla.org/mozilla-central/file/5b4c240e1a36/layout/ipc/RenderFrameParent.cpp#l247

Converting stuff from using the chromium MessageLoop to the xpcom threading stuff doesn't appear to be trivial. In particular, doing a NS_DispatchToCurrentThread on the compositor thread silently drops the runnable that was requested, which is pretty bad. We might have to do some workaround to fix this bug. Fixing bug 1145090 *might* do it, but I'm not sure.

Any updates here? This assertion is still triggering with current builds.

Not really. I wanted to talk to :bent about the threading things at Whistler but he wasn't there, and now he's leaving anyway. I think the best option at this point is to comment out the assertion and to fix bug 1145090 as soon as we can. It's not really a high priority right now but I can put it on the backlog so we get to it quicker.

This should prevent the assertion from tripping.

I decided to file bug 1180860 for the root cause, and close this one out since otherwise it will probably just sit around forever.