Closed Bug 1161407 Opened 5 years ago Closed 5 years ago
APZC: WARNING: Dropping task posted to controller thread
My terminal is flooded with this warning: [Parent 46797] WARNING: Dropping task posted to controller thread: file ./gfx/layers/apz/util/APZThreadUtils.cpp, line 70 It happens every time I scroll inside a remote iframe. Configuration: - B2G Desktop - APZC enabled - OSX - scrolling with the trackpad Is there anything I can do to help figuring out what's going on?
Do you have layers.async-pan-zoom.separate-event-thread set to true? If so set it back to false. Also make sure your build has bug 1148868. If you still see it then add logging at http://hg.mozilla.org/mozilla-central/annotate/754579ec0e68/widget/cocoa/nsChildView.mm#l1925 to see what is happening during startup.
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #1) > Do you have layers.async-pan-zoom.separate-event-thread set to true? If so > set it back to false. Also make sure your build has bug 1148868. It was set to false. And the patches from bug 1148868 were included. > If you > still see it then add logging at > http://hg.mozilla.org/mozilla-central/annotate/754579ec0e68/widget/cocoa/ > nsChildView.mm#l1925 to see what is happening during startup. Apparently, this function is never called. In nsBaseWidget::CreateCompositor(), IsMultiProcessWindow() is false, so ConfigureAPZCTreeManager() is never called. If I force IsMultiProcessWindow to true, nsBaseWidget::ConfigureAPZControllerThread() is called, but as soon as I try scrolling in a child process, it freezes.
We are only allowing APZ in e10s windows. If IsMultiProcessWindow is false the window is non-e10s, so APZ should not have been activated. Can you get a backtrace to the warning you reported in comment 0? Nothing should be calling that code if APZ is not activated.
Some context: - this is a special build of B2G Desktop (https://hg.mozilla.org/projects/larch) - "layers.async-pan-zoom.enabled" -> true - the window hierarchy is: . native cocoa window, (b2g/shell.html) . html:iframe non-remote mozbrowser mozapp, (app/index.html) . html:iframe remote mozbrowser, (http://cnn.com) - the last iframe is inside a overflowing div that has the attribute scrollgrab.
Oh fun. Yet another combination of platforms that we didn't properly account for. This one is cocoa widget (so we do the e10s check) but has e10s disabled (so we don't set up APZ in the parent process). However TabChild just checks the pref and not if it's an e10s child process or a remote mozbrowser process so it thinks APZ is enabled. Hence the mismatch and error. Let me figure out how we want to handle this case.
So for now I think you should be ok to locally take out the IsMultiProcessWindow check (which I moved to CompositorParent yesterday in bug 1162179) so that APZ is enabled in your non-e10s windows. The freezing you were seeing in comment 2 was likely bug 1161040 and should be fixed in central. Let me know if you still have problems with that.
Appears to work well now.
Attachment #8603252 - Flags: review?(bugmail.mozilla)
Comment on attachment 8603252 [details] [diff] [review] v1 Review of attachment 8603252 [details] [diff] [review]: ----------------------------------------------------------------- Please update the comment inside the ifdef to explicitly mention the use of moz_b2g instead of moz_widget_gonk to capture b2g desktop environments.
Attachment #8603252 - Flags: review?(bugmail.mozilla) → review+
Assignee: nobody → paul
You need to log in before you can comment on or make changes to this bug.