Now that there is only ever a single handle to the `CompositionRecorder`, it no
longer needs to be ref-counted. And since the `WebRenderCompositionRecorder` is
owned exclusively by the `RenderThread`, it no longer needs a mutex. All the
code that resulted from having handles to the `WebRenderCompositionRecorder` on
two different threads is now no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39791
--HG--
extra : moz-landing-system : lando
Since we are not writing frames to disk from the `CompositorBridgeParent` in
the WebRender case, we do not actually need a handle to the
`(WebRender)CompositionRecorder` there. Instead, the `HostLayerManager` and
`RenderThread` can maintain exclusive handles to these objects. This will allow
us to use unique pointers for these objects and delete code in a follow up
patch.
Differential Revision: https://phabricator.services.mozilla.com/D39790
--HG--
extra : moz-landing-system : lando
On macOS, if we try to write the collected frames from the
`CompositorBridgeParent` we will not have an active GL context, resulting in a
crash. Writing the frames from the `RenderThread` solves this problem.
Differential Revision: https://phabricator.services.mozilla.com/D39789
--HG--
extra : moz-landing-system : lando
Instead of blindly attempting to write frames to disk, we now ensure that the
`CompositionRecorder` exists. In the case where we have not allocated one,
calling `windowUtils.setCompositionRecording(false)` will instead print an
error message to the browser console.
In addition, attempting to call `windowUtils.setCompositionRecording(true)`
while a `CompositionRecorder` exists will also result in an error message.
Differential Revision: https://phabricator.services.mozilla.com/D39584
--HG--
extra : moz-landing-system : lando
Fix for the Bug 1536744 removed abiliti for nsIProtocolHandler to parse URLs of the
custom protocols & broke libdweb. In order to fix followup change for Bug 1559356 introduced a
whitelist for dweb: and dat: protocols to parse those as nsIStandardURLs. This change extends
whitelist with ipfs: ipns: ssb: schemes and ext+ prefix scheme.
This would allow Bug 1271553 to progress until better more general solution can be implemnted.
Differential Revision: https://phabricator.services.mozilla.com/D39463
--HG--
extra : moz-landing-system : lando
We could get rid of the need to specify the impl class at the callsite by
taking a T** instead of returning an already_AddRefed<T>, but I'm not sure
which is uglier...
The change from `globalHolder->GetGlobalJSObject()` to `global.Get()` is OK,
because `globalHolder` was coming from the nsISupports attached to
`global.Get()` anyway, so those are the same global JS object.
Differential Revision: https://phabricator.services.mozilla.com/D40060
--HG--
extra : moz-landing-system : lando
Use thread actor reference instead of target's actor URL *and* connection
to distinguish the currently paused event loop from the other ones which
may be on-pause from another thread actor on another connection/tab.
This happens when connecting more than one client against the same tab.
Differential Revision: https://phabricator.services.mozilla.com/D39705
--HG--
extra : moz-landing-system : lando
pre and post nest functions are rather something specific to the thread actor
or the event loop classes. The only reason it is today on the target actors
is that the list of targetted windows can be different based on the target.
But we can figure out, from the thread actor's debuggees, the list of these
windows that are inspected by the thread actor.
I think that it is better that was as it better reflect what actual final
globals, the thread actor is interacting with. The previous code could possibly
introduce differences between globals for which we pauses the timeouts and events
versus the globals being inspected by the thread actor.
Differential Revision: https://phabricator.services.mozilla.com/D39186
--HG--
extra : moz-landing-system : lando
Exceptions can be something else than `Error`.
An example could be `Cu.Exception()`, but native code can probably throw
unexpected things. It is also possible to throw any kind of object in JS...
Differential Revision: https://phabricator.services.mozilla.com/D39185
--HG--
extra : moz-landing-system : lando
Instead of reporting the pixel differences in a logger info message,
put it in the text that's returned to the harness. This has a notable
advantage on android where this will cause it to be logged as part of
the harness logs rather than ending up in the logcat from the
device. It also makes these messages more accessible in other
consumers of the logs e.g. wpt.fyi.
Differential Revision: https://phabricator.services.mozilla.com/D40064
--HG--
extra : moz-landing-system : lando
When checking for an update during startup, open the update.status file with read and write access so repeated update attempts are prevented when there is only read access to the update.status file.
When loading the active-update.xml file after startup, open it with both read and write access so the active-update.xml isn't loaded when there is only read access and the client will still receive manual update notifications.
On Windows, when opening the active-update.xml file with both read and write access fails attempt to fix the update directory permissions.
When checking if it is possible to apply updates, first check for write access to the update directory so OS X no longer always returns true and Windows no longer always returns true when the maintenance service can be used.
Sets security.turn_off_all_security_so_that_viruses_can_take_over_this_computer to true in the app update xpcshell tests so Cu.isInAutomation is true when running the tests.
Differential Revision: https://phabricator.services.mozilla.com/D39601
--HG--
rename : toolkit/mozapps/update/tests/unit_base_updater/marAppApplyUpdateSuccess.js => toolkit/mozapps/update/tests/unit_base_updater/marAppApplyUpdateSkippedWriteAccess_win.js
extra : moz-landing-system : lando
GetFunctionPrototype already returns null for 'normal' functions. Eventually
the real %FunctionPrototype% is provided based on the class proto key.
Differential Revision: https://phabricator.services.mozilla.com/D39770
--HG--
extra : moz-landing-system : lando
This is a good preparation fo deferred function allocation (Bug 1569315),
but also removes some awkward rooting / type issues in deferred lazyscript
allocation
Differential Revision: https://phabricator.services.mozilla.com/D39745
--HG--
extra : moz-landing-system : lando
I needed empty blobs in MediaRecorder and seeing that there was no
Blob::CreateEmptyBlob, nor an export of EmptyBlobImpl, I thought
Blob::CreateEmptyBlob would be the cleaner solution, so here it is.
Differential Revision: https://phabricator.services.mozilla.com/D35310
--HG--
extra : moz-landing-system : lando
This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
This first of all does some refactoring of how metadata is encoded in
MediaEncoder. This is now guided by the new Muxer class. If we're ready to pass
data to the muxer and it does not have metadata yet, we provide metadata before
giving it any media data. This metadata is passed to the muxer in a single call.
The metadata provided in this call must stay valid for the entire recording.
This removes MediaEncoder::GetEncodedMetadata().
This also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.
ContainerWriter instances are updated somewhat, to accommodate these changes.
Lastly, and most important, the new Muxer class manages muxing of the (up to)
two tracks into a single container, ensuring that timestamps increase
monotonically throughout a recording.
Differential Revision: https://phabricator.services.mozilla.com/D35306
--HG--
extra : moz-landing-system : lando
Update MediaEncoder to pass frames to the muxer in order of their time stamps.
This should prevent the currently possible scenario where audio and video
frames are written with non-monotonically increasing timestamps (in violation
of the webm spec).
Differential Revision: https://phabricator.services.mozilla.com/D35388
--HG--
extra : moz-landing-system : lando
MediaQueue provides a better interface for interleaving frames when writing to
the muxer (this change will follow in another changeset). The queue interface
provides a nicer abstraction than manually managing a nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D35387
--HG--
extra : moz-landing-system : lando
This changes EncodedFrame to behave more like MediaData, so that EncodedFrame
can be used with the MediaQueue data structure. It also provides a somewhat
more consistent interface across media data types.
Differential Revision: https://phabricator.services.mozilla.com/D35386
--HG--
extra : moz-landing-system : lando
Move the responsibility of adjusting opus frame timestamps to the MediaEncoder.
This was previously done by the EbmlComposer, but doing so in the MediaEncoder
means we can have greater control over handling of time codes and interleaving
of frames.
Differential Revision: https://phabricator.services.mozilla.com/D35385
--HG--
extra : moz-landing-system : lando
Remove EncodedFrameContainer and clean up areas where it was used.
EncodedFrameContainer provided a wrapper around an
nsTArray<RefPtr<EncodedFrame>>, but it simplifies the code to simply expose
this array. Also clean up unused enums in EncodedFrame, and clean up some of
the outdated comments for our encoded frame handling.
Differential Revision: https://phabricator.services.mozilla.com/D35384
--HG--
rename : dom/media/encoder/EncodedFrameContainer.h => dom/media/encoder/EncodedFrame.h
extra : moz-landing-system : lando
Separating the encode and mux steps allows for better control over interleaving
audio and video data. If encode and mux are done in a single step it's possible
to mux large amounts of audio or video data which should have been interleaved
with the other data type to give correctly ordered time stamps in the target
container.
Differential Revision: https://phabricator.services.mozilla.com/D35383
--HG--
extra : moz-landing-system : lando
This patch replaces the fake tracker numbers with the real data from the
TrackingDBService. We will pre-fetch the counter while hovering on the
shield icon in order to avoid a flicker on updating the counter. And we
make the tracker counter be hidden by default, then display it when
there is at least one record. We also add a css transition for
avoiding the flicker.
In addition, we rename some member variable in gProtectionsHandler.
Differential Revision: https://phabricator.services.mozilla.com/D39695
--HG--
extra : moz-landing-system : lando
This patch implements the tooltip for showing the earliest date of the
block tracker record. The tooltip will be set during the initiation
gProtectionHandler module. And it will be updated if history has been
cleared. If there is no record, we won't do anyhting since the tracker
counter will be hidden entirely.
We also add an event handler for the hovar and focus state on the shield
icon in order to pre-fetch the data from tracking database. And we will
update the date here in case that there is no record during initition
but a new record comes later. The focus event is for the keyboard
navigation feature.
Differential Revision: https://phabricator.services.mozilla.com/D39694
--HG--
extra : moz-landing-system : lando
This patch adds two strings, one for the blocked tracker counter and
another for the tooltip.
Differential Revision: https://phabricator.services.mozilla.com/D39693
--HG--
extra : moz-landing-system : lando
