This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
WebGPU itself doesn't care about WebRender or even the GPU process.
However, the presentation to canvas as written today only works with WebRender, so
it seems fine to have it as a dependency in general.
An alternative could be to just fail getContext() call if webrender is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D70888
for consistency with ErrorResult and dom::Promise, which will mean no reverse
conversion is required for rejecting Promises.
Differential Revision: https://phabricator.services.mozilla.com/D95967
It's an empty, useless interface after the previous patches. Also remove
a bunch of expired geolocation probes which were null-checking the requester
object for some reason.
Depends on D96882
Differential Revision: https://phabricator.services.mozilla.com/D96883
This patch include some additional changes to the diagnostic assert to be able to include:
- the error name for the E10SUtils call failure
- the file name and line number that originated the error
The change itself does not include a new automated test, but I did verify locally the new expected crash message:
- by temporarily a js error and a Components.Exception to be thrown while running one of the existing tests (dom/workers/test/xpcshell/test_remoteworker_launch_new_process.js).
- and also temporarily forcing the failure while the method is being called in both the parent and child processes.
Differential Revision: https://phabricator.services.mozilla.com/D96598
As cubeb might call audio stream's state callback very soon after we start cubeb, we have to create the promise beforehand in order to handle the case where we immediately get `drained`.
Differential Revision: https://phabricator.services.mozilla.com/D96770
In the change from bug1674597, AudioSinkWrapper only handles the promise when we succeed opening AudioSink. However, it forgots to handle the promise when fail to start AudioSink.
Differential Revision: https://phabricator.services.mozilla.com/D96738
This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).
Differential Revision: https://phabricator.services.mozilla.com/D96978
We also ensure that the MediaFormatReader will only shutdown once the CreateDecoderPromise has been resolved (or rejected)
This makes a few of the earlier changes redundant; as we can now guarantee all the objects provided to the PDMFactory will stay valid for the entire lifetime of the decoder. So we could do away with P4 and P7.
It's better that we keep those however, as it greatly simplify other usage of the PDMFactory. Ensuring that the user of the PDMFactory survives any decoder isn't a trivial affair.
Differential Revision: https://phabricator.services.mozilla.com/D96369
P4 introduced a cycle between the MediaFormatReader and the onWaitingForKeyEvent lambda.
Normally, this cycle would be broken by a call to Shutdown.
However, should the MediaFormatReader shuts down before the CreateDecoderPromise be resolved, it would have no way of shutting down the decoder keeping the cycle alive.
Theoretically, keeping a plain pointer to the MFR::mOnTrackWaitingForKey like we did before P4 is safe, as the EME code making use of it, only does so while we are decoding data and the MFR has the ability to properly shutdown the decoder.
However, for the sake of clarity and simplification, we introduce an easier way to check of the MFR has been deleted already by making it support SafeThreadWeakPtr; and the OnWaitingForKey keep a weak pointer to it and checking the value before calling it.
Differential Revision: https://phabricator.services.mozilla.com/D96367
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
Until now, it was up to the caller to ensure that the VideoInfo or AudioInfo passed to the PlatformDecoderModule would remain alive until the created decoder was shut down.
This was achieved by the MediaFormatReader through great care and complexity and ensuring that the MediaFormatReader would never complete its own shutdown unless the decoder did the same.
Asynchronously creating the decoder add an even greater of complexity. We have to ensure that should the caller shut down while the decoder creation promise hasn't been resolved ; that it stays alive the entire time.
It could be achieved by making the TrackInfo object refcounted, or creating a cycle between the caller and the PDM/decoder.
Each of those options have their own downsides.
Either of those options add an unwarranted level of complexity, when we can just have each decoder copy the arguments it receives. This is simpler and more straightforward and the required copy isn't expensive.
Differential Revision: https://phabricator.services.mozilla.com/D96363
For now, creation of the decoders is a synchronous operation, so we can deal with a convenience, stack-only structure to pass all the parameters required.
This will change once creation becomes asynchronous and we must ensure that the parameters lifetime will overlap the entire process.
It also allows to simplify the few areas that did have to manually copy all those parameters and save them individually.
Differential Revision: https://phabricator.services.mozilla.com/D96361
Passing a pointer to an object across several thread was dubious at best to ensure a use after free was never in place.
This complexity becomes even greater should we want to create the decoder asynchronously.
So we pass instead a lambda that holds a strong reference to the object that holds the event producer.
Differential Revision: https://phabricator.services.mozilla.com/D96360
There's no longer have a GpuDecoderModule and RemoteGpuDecoder.
So we no longer need the IRemoteDecoderChild abstraction layer.
Differential Revision: https://phabricator.services.mozilla.com/D96359
The DecoderDoctorDiagnostic is only ever used with PDM::Supports; when creating a decoder this object would always be nullptr.
Attempting to set it would have resulted in UAF as a DiagnosticDecoderDecoder is typically an object allocated on the stack and most of the code creating the decoders is async.
Differential Revision: https://phabricator.services.mozilla.com/D96358
This method will become the main entry point of a PDM and allow to create a decoder asynchronously for PDM not supporting that interface.
Differential Revision: https://phabricator.services.mozilla.com/D96357
We also ensure that the MediaFormatReader will only shutdown once the CreateDecoderPromise has been resolved (or rejected)
This makes a few of the earlier changes redundant; as we can now guarantee all the objects provided to the PDMFactory will stay valid for the entire lifetime of the decoder. So we could do away with P4 and P7.
It's better that we keep those however, as it greatly simplify other usage of the PDMFactory. Ensuring that the user of the PDMFactory survives any decoder isn't a trivial affair.
Differential Revision: https://phabricator.services.mozilla.com/D96369
Razvan Maries
Andi-Bogdan Postelnicu
Andreas Farre
Nika Layzell
Dzmitry Malyshau
pbz
Paul Adenot
Kagami Sascha Rosylight
Emilio Cobos Alvarez
Karl Tomlinson
Valentin Gosu
Jeff Gilbert
Haik Aftandilian
Chun-Min Chang
Luca Greco
Jan Varga
Steve Fink
alwu
Cristina Coroiu
Jonathan Kew
Dorel Luca
Jean-Yves Avenard
Bogdan Tara