This change brings the related ShMem code from VRManager and VRService into a
new class, VRShMem. This is to support future work where this ShMem will be used
for other efforts. Having this code in the same class will enable it to be more
easily shared in these efforts.
Until the new class replaces the code in VRManager and VRService, it can be
exercised and validated with two instances of vrtesthost, with the -testmgr and
-testsvc parameters.
Differential Revision: https://phabricator.services.mozilla.com/D36649
--HG--
extra : moz-landing-system : lando
gfxVRPuppet will be replaced with a fully asynchronous puppet automation that runs in the VR process.
Differential Revision: https://phabricator.services.mozilla.com/D26263
--HG--
extra : moz-landing-system : lando
The patch also removes the dom.vr.oculus.quit.timeout pref, because it's
unused.
Differential Revision: https://phabricator.services.mozilla.com/D35973
--HG--
extra : rebase_source : bd16ed5ff0b7c2b4f8e653e9835610b25b14a39f
Remove unecessary Unregister method.
The method is called only once and right prior the parent object gets deleted.
There could be a case where the VRProcessManager destructor gets called before xpcom's shutdown. This would have lead to the now deleted object being called by the Preferences.
Differential Revision: https://phabricator.services.mozilla.com//D32688
--HG--
extra : amend_source : 20b8b4740030ab141856d753a3801b55d607eea3
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
It would have been nicer and more logical to use a MacIOSurfaceImage to store the colorspace information, however the data passed around is a IOSurface Id via a SurfaceDescriptorMacIOSurface; the original data structure isn't kept; so we must transit the data at the same time as the IOSurface Id.
Also remove unnecessary test (new operator is infallible).
Differential Revision: https://phabricator.services.mozilla.com/D26058
--HG--
extra : moz-landing-system : lando
When the compositor thread has begun shutdown, it will spin the event
loop for the main thread until the last CompositorThreadHolder reference
has been released. While spinning, new IPDL objects may be attempted to
be created which depend on the compositor thread; we should check to
ensure the compositor thread is still around before proceeding with
creation. These objects include CompositorManagerParent,
ImageBridgeParent, and VRManagerParent. Additionally there is a very
similar bug between the vsync thread and VsyncBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D23308
Moved non-POD member of VRDisplayInfo to VRDisplayHost
VRDisplayInfo is now also a POD type (And asserted so)
Use PlainOldDataSerializer for POD types in VRMessageUtils
Moved non-POD member of VRDisplayInfo to VRDisplayHost
VRDisplayInfo is now also a POD type (And asserted so)
Differential Revision: https://phabricator.services.mozilla.com/D24577
--HG--
extra : moz-landing-system : lando
WebVR will not initialize correctly (VR process will not be started and the headset data is frozen) for subsequent sessions in a new tab once the VR process has been shut down due to being idle.
Differential Revision: https://phabricator.services.mozilla.com/D23027
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
This change updates the structs VRDisplayState, VRLayer_2D_Content, and VRLayer_Stereo_Immersive to not have 'm' prefix for its members.
Differential Revision: https://phabricator.services.mozilla.com/D16000
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This change fixes a compiler warning, where a VRSensorState object is returned on the stack as a rather large object.
To address this warning, the return type of VRDisplayExternal::GetSensorState now returns a const reference to the member. The rest of the change are updates to uphold the new constness.
Differential Revision: https://phabricator.services.mozilla.com/D13586
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
We are refactoring much of the code in gfx/vr, moving
most of the code that runs in the VRListenerThread into
it's own process. The remaining code will be non-blocking
once this refactoring is complete.
In order to resolve some shutdown crashes, it is simpler
to remove the VRListenerThread and the related code
starting and stopping this thread. If this is done
prior to completion of the refactoring for Bug 1473399
(Enable VRService thread by default), there would be a
regression in responsiveness during detection of VR
hardware due to blocking API calls moving off the thread.
Differential Revision: https://phabricator.services.mozilla.com/D7227
--HG--
extra : moz-landing-system : lando
During shutdown, VRManager::RunTasks may be run outside
of the VR Listener thread due to residual nsTimer events.
This results in intermittent assertions during shutdown
when the assert is hit.
We do not need to run these periodic tasks during shutdown
so we can simply early-exit here.
Differential Revision: https://phabricator.services.mozilla.com/D7022
--HG--
extra : moz-landing-system : lando
- Implemented 1ms, 10ms, and 100ms VR tasks, dispatched from
VRManager
- Removed Android-specific code that compensated for
tasks that did not run when the...
...compositor was paused.
Differential Revision: https://phabricator.services.mozilla.com/D3378
--HG--
extra : moz-landing-system : lando
* Avoid writing past an XPCOM string's length using BeginWriting().
* Instead of having a constant for max path length, query the
Windows API for the length it wants.
* Avoid using AppendPrintf for mere concatenation using arguments
that might contain non-ASCII.
MozReview-Commit-ID: 9m7xOHRTB35
Differential Revision: https://phabricator.services.mozilla.com/D5349
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
The WebVR api was returning a headset pose predicted one additional frame in the
future, but the SteamVR async reprojection was reprojecting it using the
prior (correct) frame's pose.
This resulted in a sickness inducing swimming effect as well as deregistration
from the Vive chaperone bounds.
Differential Revision: https://phabricator.services.mozilla.com/D2693
--HG--
extra : moz-landing-system : lando
- Refactored gfxVROpenVR to use gfxVRExternal interface from the
VR Service. Existing gfxVROpenVR left in place (for now) to
allow VR service to be enabled or disabled by pref.
- The VR service, containing gfxVROpenVR, is to run in-process within
its own thread first, then to be later moved to its own process.
- Fixed periodic immersive mode flicker that occured due to HMD pose and
HMD state being separately sampled from the Shmem. It was possible
to advance a frame without also getting an updated pose if a dirty
copy of the shmem was detected.
MozReview-Commit-ID: IvpJErmi5kF
--HG--
extra : rebase_source : 0e21d3414a13dc514c3035f2bd5f6adc365b465d
- The VR External interface/shmem and gfxVRExternal are
updated to enable entering VR, exiting VR, and submitting
frames.
- You can now construct gfxVRExternal using a pointer to
the VR External API shmem, if it is created elsewhere.
MozReview-Commit-ID: LZuoLvoEmKO
--HG--
extra : rebase_source : ab38ae4c34f9ac5cdd69e7222f12b1c758307057
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
- gfxVRExternal Enables other processes to present
real or simulated VR hardware to Firefox.
- This functionality is disabled by default, under
dom.vr.external.enabled.
- VRDisplayInfo, VRControllerInfo, and associated
structs have been restructured to ensure internal
state is not exposed via shmem interface.
- Some refactoring to convert structs to
POD types, enabling them to be located
in shmem and be memcpy'd.
- Work needed before unpreffing marked
with "TODO" comments.
MozReview-Commit-ID: FbsusbxuoQ8
--HG--
extra : rebase_source : 8a448169c3f47411c705a4d9fd462a1f9363dfd9
extra : amend_source : e6702549527292e2850d16e8f503f0be9848159f
When ContentChild::RecvInitRendering is received, it tries to setup the
IPDL actors related to rendering. If the GPU process crashes before or
during this process, it will fail, and cause the content process to
crash as well. This is unnecessary because the UI process will either
restart the GPU process, or subsume its job into itself, and trigger
ContentChild::RecvReinitRendering. It is a similar case for failures in
ContentChild::RecvReinitRendering.
Since the GPU process crashing should be a recoverable scenario, we now
check if the remote IPDL actor is in the UI or the GPU process. If it is
in the UI process, it will fail/crash as it does today. If it is in the
GPU process, it will wait for the next
ContentChild::RecvReinitRendering.
For failures that are not IPDL related (e.g. failed to get some resource
like spawning a thread), we release assert specifically for those
failures. They are not recoverable.
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
- Add pref to enable the ovrInit_Invisible flag for Oculus sessions, enabled by default.
- Ensure that the Oculus library is unloaded every time it is uninitialized,
improving reliability of exiting and returning to WebVR.
MozReview-Commit-ID: 6VCugCJ2dUz
--HG--
extra : rebase_source : c6002bbaab650a86a31f62b63029f13ce2c8f614
- Update prefs to accomodate tests, disabling
enumeration throttling
- Updated Puppet display and controller implementation
to act more like the actual devices.
- Updated tests to ensure that they explicitly
create a VR mock display and don't create duplicate
mock displays.
MozReview-Commit-ID: 6RPVqekG2je
--HG--
extra : rebase_source : 9cc9ea116114cc191edbf5a01ac8f84fff9709c4
- Ensure ovr_GetSessionStatus is polled even when a VR presentation
is not active.
- When we fail to initialize an Oculus Session or detect VR hardware,
immediately unload the Oculus Library as we can't poll for ShouldQuit
without a valid Oculus session.
- When we poll ovr_GetSessionStatus, we are now updating the mounted state
in VRDisplayInfo::mIsMounted.
- Added prefs to control enumeration throttling and timeout to release
VR hardware when inactive.
- Some refactoring to make frame loop more understandable and less
brittle.
- When throttling enumeration, we ensure that all other VR apis
also throttle enumeration so that they don't pick up the same device
during throttling.
- Some long functions in VRManager have been broken up and
had their inner-workings documented in more detail.
MozReview-Commit-ID: CEYwwQ9mYd0
--HG--
extra : rebase_source : b2ab0dfc17b9ddc06f6afafdf69497fb9418fd47
- As we are creating a separate VR process in Bug 1362578,
we will need our own D3D11Device.
- Eventually, we will be allowing the VR device runtimes to
help select the appropriate adapter / device based on the
physical connection. This function will be updated at that
time.
MozReview-Commit-ID: EewUkNxU3BI
--HG--
extra : rebase_source : d89dd4dcc71f2b0dc54711f50628ee3bc494b73e
- This IPC is no longer used and can be removed to simplify
the PVRManager protocol.
MozReview-Commit-ID: Kno5CHkI17K
--HG--
extra : rebase_source : 227e36b00bc2d6a3b83b48d80fbfdfe35196057d
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "^\* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1="\* This Source Code Form is subject to the terms of the Mozilla Public"
line2="\* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3="\* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Insert 1 space at beginning:
sed -i s%"^$line1"%" $line1"% $1
sed -i s%"^$line2"%" $line2"% $1
sed -i s%"^$line3"%" $line3"% $1
###
MozReview-Commit-ID: HXBMrfnhlVr
--HG--
extra : rebase_source : de4c78563711f8366e2978c5199a5041875fbe38
- Oculus SDK was updated from 1.5 to 1.9
- As the Oculus API now returns quaternion orientations for each
eye-to-head transform, I needed to send more information to the
content process.
- Rather than adding the quaternion, we now calculate the view matrices
on the VR thread in the GPU process rather than calculating it in the
content thread from parameters.
- OpenVR's full view matrix is now used, for compatibility with more devices.
- IPD adjustments are now updated every frame for both Oculus and OpenVR.
MozReview-Commit-ID: LOtfs4QIqc8
--HG--
extra : rebase_source : 0a69824012ede4bea0e0e709a2d027d0c35730bb
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
- VRManagerChild no longer needs to be a TextureForwarder
- VRManagerParent no longer descends from HostIPCAllocator or ShmemAllocator
- PVRManager no longer manages PTexture's
- VRLayerParent::mSize was not used and has been removed
MozReview-Commit-ID: 3bNN5FR5j7M
--HG--
extra : rebase_source : 634277825c00057bca6f8c77cdc942de61d61e9c
- WebVR is no longer dependent on PTexture, TextureParent,
TextureHost, and TextureChild. It continues to use TextureClient
for pooling and coordinating locks with other Gecko code.
- PreserveDrawingBuffer now behaving correctly for 2d display mirroring
- Preparation for separating to VR process
MozReview-Commit-ID: 2RGOulCInSu
--HG--
extra : rebase_source : 3542b804c3def36fa74541be32d0e7cbc9698641
- A user gesture is required only for the VRDisplay.requestPresent
call that initiates the VR presentation, as per the WebVR 1.1 spec.
- The parameters of the VRLayer can now be updated by calling
VRDisplay.requestPresent on an active VR presentation.
- Dynamic resolution switching is now functional:
https://webvr.info/samples/08-dynamic-resolution.html
iMozReview-Commit-ID: BL7aJfF6nqR
MozReview-Commit-ID: CmhbFJ4ij5q
--HG--
extra : rebase_source : 28a3f608b4f821631e81ccdfe7f7824f9508a7b4
- Using a separate ID3DDeviceContextState ensures
that the WebVR context does not stomp over the
mirrored state used by the MLGPU "Advanced" Layers rendering.
MozReview-Commit-ID: 99mfdsjFrMI
--HG--
extra : rebase_source : 599df3b1344ca1489cbb13169313dff8e767c399
- Using a separate ID3DDeviceContextState ensures
that the WebVR context does not stomp over the
mirrored state used by the MLGPU "Advanced" Layers rendering.
MozReview-Commit-ID: 99mfdsjFrMI
--HG--
extra : rebase_source : fdcdcb55185048cfb54163f51aca70409a1aa74a
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.