47 bytes, text/x-phabricator-request
|Details | Review|
We currently run into this assertion when adding an observer if the pref is on : https://searchfox.org/mozilla-central/rev/8848b9741fc4ee4e9bc3ae83ea0fc048da39979f/hal/Hal.cpp#341 See https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=203724772&revision=7584dc7444f0526cb0844d16b193c3431f876f27 for a very messy couple of patches that address the issue.
Taking this for now.
Assignee: nobody → mconley
It looks like the wakelock stuff was added for b2g back in bug 999327, and ultimately what it appears to do now is set the mHighPriority boolean here: https://searchfox.org/mozilla-central/rev/2e5e28f518524f8af5b158ddb605022b6a2d68cf/dom/ipc/ProcessPriorityManager.cpp#503,505 But that mHighPriority boolean doesn't appear to be used anywhere anymore. It _was_ used when bug 999327 originally landed, but stopped being used in bug 1119277. I think we can just tear out this wakelock observer for the process priority manager for now, since it doesn't appear to be used by anyone (in particular, doesn't appear to be used by Fennec or GeckoView).
Yes, IIRC high-priority wakelocks were used exclusively for Firefox OS' dialer application so they're long gone.
The WakeLockObserver is being used to set a boolean that's never being read. This also makes it so that dom.ipc.processPriorityManager.enabled can be set to true by default. Without this patch, setting that pref to true by default means that the WakeLockObserver attempts to be registered before Hal has had a chance to initialize which causes an assertion failure.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/ec0c3354ab22 Don't register WakeLockObserver for ProcessPriorityManagerImpl. r=gsvelto
You need to log in before you can comment on or make changes to this bug.