Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
Primarily, this removes code that was compensating for inconsistencies between webrtc.org's timestamps, and JS timestamps. Also, this removes a few bits of indirection on GetRtpSources; that's all going to go directly to RTCRtpReceiver now. None of this code is being moved elsewhere.
Depends on D50395
Differential Revision: https://phabricator.services.mozilla.com/D64234
--HG--
extra : moz-landing-system : lando
Primarily, this removes code that was compensating for inconsistencies between webrtc.org's timestamps, and JS timestamps. Also, this removes a few bits of indirection on GetRtpSources; that's all going to go directly to RTCRtpReceiver now. None of this code is being moved elsewhere.
Depends on D50395
Differential Revision: https://phabricator.services.mozilla.com/D64234
--HG--
extra : moz-landing-system : lando
There are several tests using similar methods of playing/pausing media, and we should make them as util functions to share the same code.
Differential Revision: https://phabricator.services.mozilla.com/D67382
--HG--
extra : moz-landing-system : lando
I made some changes in preparation for removing nsIScriptError.flags in favor
of nsIConsoleMessage.logLevel.
Differential Revision: https://phabricator.services.mozilla.com/D66878
--HG--
extra : moz-landing-system : lando
A declare of a pointer in the init-statement within if need to be
checked if it's a NULL before it's being used, to avoid a potential
crash.
To prevent any goes wrong in mMediaSessionInfoMap and lead to create a
null BrowsingContext pointer from it, using an assertion is more
straightforward.
Differential Revision: https://phabricator.services.mozilla.com/D66491
--HG--
extra : moz-landing-system : lando
Those are needed, respectively to be able to ensure the stream doesn't go away
when messaging back to the control thread, and then to access the details of the
exception thrown.
Differential Revision: https://phabricator.services.mozilla.com/D64765
--HG--
extra : moz-landing-system : lando
Having nested AutoJSAPI clobbers the exception value of the innermost one on
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D64763
--HG--
extra : moz-landing-system : lando
The produce the same outcome as originally done in bug 1487797. However, we only do so on the last block ever retrieved.
Ideally, we should calculate the start time based on the number of frames previously returned. It would avoid such inconsistency and while we had one file presenting such symptom, I'm not sure we can always rely for the frame_or_sample_num value to be valid in reference to the first frame block size.
Depends on D66989
Differential Revision: https://phabricator.services.mozilla.com/D66990
--HG--
extra : moz-landing-system : lando
It didn't take into account that there could be a mixture of variable block size and fixed block size and could use the start time of an invalid block to determine the end of the previous frame as the code relied on Frame::FindNext() to have always returning a valid frame; but this isn't always the case.
We also want to keep the scope of each classes separate, so that it is up to the FrameParser to correct a Frame should it be invalid or not set properly.
Differential Revision: https://phabricator.services.mozilla.com/D66989
--HG--
extra : moz-landing-system : lando
Remove old content sandbox code paths that allowed the sandbox to be started
later during content process startup when the SetProcessSandbox() message was
received from the parent process. This older way of starting the sandbox was
still in the tree to support WebReplay which is now being removed. With this
fix, content processes always use the "earlyinit" sandbox startup like the
RDD and GMP processes.
Differential Revision: https://phabricator.services.mozilla.com/D64968
--HG--
extra : moz-landing-system : lando
On X11, there is an universal definition for `None`, and it conflicts with the `None` in the enum of `MediaSessionPlaybackTestState`, which causes a build fail on X11. Also, as the `MediaSessionPlaybackTestState` is defined in the `ChromeUtilsBinding.h`, which is automatically generated by the code gen, we can't include `X11UndefineNone.h` to workaround this problem.
Therefore, we have to change its name to avoid using the same name.
[1] from `/usr/include/X11/X.h:115`
#define None 0L /* universal null resource or null atom */
Differential Revision: https://phabricator.services.mozilla.com/D66445
--HG--
extra : moz-landing-system : lando
Implement a chrome-only method `getCurrentMediaSessionPlaybackState()` to expose current actual playback state in testing.
The reason we create an new enum `MediaSessionPlaybackTestState` is because of building issue. If we use `MediaSessionPlaybackState` directly in the `ChromeUtils.webidl`, then the codegen would automatically add an header include of `MediaSessionBinding.h` in the `ChromeUtilsBinding.h`, which would cause the complier complaining about lots of undeclared identifier.
Differential Revision: https://phabricator.services.mozilla.com/D66344
--HG--
extra : moz-landing-system : lando
`PlaybackState` and `MediaSessionPlaybackState` are actually quite similar, and we don't want to have to many states to confuse reader and do unnecessary tranform between two states. Therefore, replaceing `PlaybackState` with `MediaSessionPlaybackState`.
Differential Revision: https://phabricator.services.mozilla.com/D66342
--HG--
extra : moz-landing-system : lando
This patch includes the implementation of propagating declared playback state from the media session in the content process to the media session controller in the chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D66341
--HG--
extra : moz-landing-system : lando
As we would need to preserve media session's playback state as well, we create a new struture to store each media session's propagated properties.
Differential Revision: https://phabricator.services.mozilla.com/D66340
--HG--
extra : moz-landing-system : lando