This patch does two things:
1) Extracts data before firing "start", instead of after, so that any
`requestData()` or timeslice-based "dataavailable" event fired immediately
after "start" contains data.
2) Sets mLastBlobTimeStamp on encoder initialization instead of session
construction, so that any "dataavailable" events are held back until some
actual data has been gathered.
Differential Revision: https://phabricator.services.mozilla.com/D46466
--HG--
extra : moz-landing-system : lando
With spec compliant mime type handling we no longer fire "error" on start for a
audio-only recording of a (currently) video-only MediaStream.
This patch adapts the test to more accurately name what we originally wanted to
test - that pause() after an error doesn't crash but throws. It does this by
triggering another kind of error, one that happens because we try to remove
the recorded track from the recorded stream. We still keep the behavior of
start()ing the recording before any supported tracks are available, because we
support that.
To clarify what this test is actually testing, this patch also modernizes the
code with async/await to linearize the testing of events and their order.
Differential Revision: https://phabricator.services.mozilla.com/D17811
--HG--
rename : dom/media/test/test_mediarecorder_unsupported_src.html => dom/media/test/test_mediarecorder_onerror_pause.html
extra : moz-landing-system : lando
This test relied on us choosing to record audio/ogg because of the only audio
track, which would fail and result in an error with ogg support disabled.
We now per spec select mime type synchronously on construction instead of after
detecting the stream's tracks - and so fall back to video/webm when the mime
type is defaulted. With this the test times out because we're recording fine.
When disabling also webm encoding we follow the spec's "note that this case is
essentially equivalent to leaving up to the UA the choice of container and
codecs on constructor", and choose some unknown mime type that is not supported
(none are), thus ending up throwing NotSupportedError.
Not much remains of this test with these changes, and what actually remains is
covered by other tests, which warrants removal.
Differential Revision: https://phabricator.services.mozilla.com/D17810
--HG--
extra : moz-landing-system : lando
This is the last step to making the MediaRecorder's mime type handling up to
spec, and has a real effect only if the constrained mime type is empty, or doesn't
contain any codecs.
Differential Revision: https://phabricator.services.mozilla.com/D17809
--HG--
extra : moz-landing-system : lando
This leaves out support for extending the mime type with the selected container
and codecs, and support in MediaEncoder for using a specific mime type.
Differential Revision: https://phabricator.services.mozilla.com/D46463
--HG--
extra : moz-landing-system : lando
This aligns it better with MediaRecorder's timeslice which was changed from
int32 to uint32 earlier.
Differential Revision: https://phabricator.services.mozilla.com/D41586
--HG--
extra : moz-landing-system : lando
This brings the MediaRecorder constructor and start() to spec on most parts
except mime type handling (bug 1512175). The flow is also improved to better
follow along in the algorithms of the spec.
Differential Revision: https://phabricator.services.mozilla.com/D41585
--HG--
extra : moz-landing-system : lando
When a Debugger.Frame refers to a generator or async function call, the script
must be compiled with instrumentation to notify the Debugger API when the call
is resumed. To accomplish this, a generator's JSScript's DebugScript's
generatorObserverCount tracks the number of Debugger.Frames referring to calls
running the script. When the count is non-zero, instrumentation is required.
When a Debugger.Frame for a suspended generator call is garbage collected, its
JSScript's generatorObserverCount must be decremented. However, if the JSScript
is alo being garbage collected, it may have already been finalized, and should
not be touched.
The prior code had js::DebuggerFrame::finalize use IsAboutToBeFinalized to check
whether the JSScript was healthy enough to have its count decremented. Since the
garbage collector always handles debuggers and debuggees in the same GC cycle,
it was believed that the JSScript's mark bit (what IsAboutToBeFinalized checks)
would be accurate.
Unfortunately, it is possible for a JSScript to be finalized in one GC slice,
and then for the mutator to run, and then for the DebuggerFrame to be finalized
in the next slice, with the JSScript's arena available for new allocations in
the middle. When an arena is made available for allocation during an incremental
GC, all its mark bits are set. As a result, the DebuggerFrame finalizer believes
that the JSScript it was referring to is still alive, even thought it has been
finalized. IsAboutToBeFinalized is only safe to use on edges between cells of
the same alloc kind, since we do promise to run all finalizers for a given alloc
kind before putting those arenas up for reuse. It's not safe to use
IsAboutToBeFinalized to inspect edges between cells of differing alloc kinds,
like DebuggerFrame JSObjects and generator JSScripts.
Fortunately, there is another approach we can take. The garbage collector calls
`DebugAPI::sweepAll` after all marking is done, but before any finalization
takes place. At this point, all cells' mark bits are accurate (assuming they're
in a zone being GC'd), but nothing has been finalized. We can disconnect
unmarked DebuggerFrames from their scripts now, knowing that both parties are
still fully initialized.
Differential Revision: https://phabricator.services.mozilla.com/D47721
--HG--
extra : moz-landing-system : lando
This works around a bug in Python:
https://bugs.python.org/issue32745
Null characters aren't allowed in 'c_wchar_p' types anymore, but we can get around
the issue by allocating a buffer in memory and casting it after the fact. This was
discovered via trial and error and I'm not really sure why it works.. But it does.
This also enables the tests under Python 3 on Windows (which thankfully all
seem to pass).
Differential Revision: https://phabricator.services.mozilla.com/D48113
--HG--
extra : moz-landing-system : lando
RustJSPrincipal is used in Servo; we just return the conservative value of 'false'.
Differential Revision: https://phabricator.services.mozilla.com/D47478
--HG--
extra : moz-landing-system : lando
Finally, here we add the virtual method isSystemOrAddonPrincipal to the
JSPrincipal object.
We also add it to nsJSPrincipal (where it has an easy implementation), and
to carry classes that are used by JS tests and the shell.
Differential Revision: https://phabricator.services.mozilla.com/D47477
--HG--
extra : moz-landing-system : lando
Unlike WorkletPrincipal, a WorkerPrincipal had been a simple static object shared by
all Workers. We never needed to consult it about an individual Worker before. Now we
do. So we cut it over from a static object to individual objects for each Worker.
We have an off main thread access problem for the Principal however, WorkerPrivate
has a method UsesSystemPrincipal that returns a bool that was initialized from the
Principal on the main thread. We copy that pattern and add a
UsesAddonOrExpandedAddonPrincipal method that will be called by the
isSystemOrAddonPrincipal method we must implement so we can inheirt from JSPrincipal.
Differential Revision: https://phabricator.services.mozilla.com/D47476
--HG--
extra : moz-landing-system : lando
WorkletPrincipal inherits JSPrincipals so we need to add the isSystemOrAddonPrincipal
method to it. As of Bug 1578623 rev a83797ed249c - Worklets are always NullPrincipal,
so we can just return false.
Differential Revision: https://phabricator.services.mozilla.com/D47475
--HG--
extra : moz-landing-system : lando
In a future commit we will tie this boolean to its own preference value, but here we
initialize it with the same value as the wasm boolean.
We also update wasm::HasSupport to check the to-be-added isSystemOrAddonPrincipal()
method on JSPrincipals to determine which member (wasm or wasmForTrustedPrinciples)
to consult.
Differential Revision: https://phabricator.services.mozilla.com/D47472
--HG--
extra : moz-landing-system : lando
CreationOptions are intended to be immutable and not change during realm operation.
Behaviors change, and clamping/jittering should reside on behaviors.
Differential Revision: https://phabricator.services.mozilla.com/D43296
--HG--
extra : moz-landing-system : lando
This patch creates the first full mochitest that exercises the profiler
popup's mechanisms of capturing profiles. The test tries to use user-focused
mechanisms–clicking buttons to fully capture a profile.
In addition, it fixes two leaks that were uncovered by the leaktest check.
The first has to do with the iframe src creating an about:blank page when
set to an empty string. The next was the Services.obs.addObserver call
in the perfFrontInterface not being removed when the page was unloaded.
Differential Revision: https://phabricator.services.mozilla.com/D45530
--HG--
extra : moz-landing-system : lando
The popup's shortcuts use a different codepath than the popup's buttons.
When using the buttons, the profile was not being captured as a gzipped
profile, and it was using the DevTools' mechanism for getting the symbol
tables. This patch makes the getSymbolTables mechanism configuring in the
recording panel's client.
In addition, browser code made its way into the client. This patch moves
the browser code to all be in browser.js to match the original code
organization for the panel, which was trying to keep browser APIs
out of the React components and Redux store.
Differential Revision: https://phabricator.services.mozilla.com/D45529
--HG--
extra : moz-landing-system : lando
Andreas Pehrson
Jonathan Kew
Noemi Erli
Jim Blandy
Emma Malysz
Jason Laster
Michael Kaply
Andrew Halberstadt
Anmol Agarwal
Tom Ritter
Dão Gottwald
Razvan Maries
Jared Wein
Greg Tatum
Morgan Reschenberg
Gurzau Raul
Luke Crouch
James Willcox