browser_exception_leak.js is intentionally creating a leak, so maybe the unused
doc is intentional.
browser_import_mapped_jsm.js is deliberately testing the behavior of Cu.import,
so ignore the failure there.
Differential Revision: https://phabricator.services.mozilla.com/D158507
One place was missing an explicit return.
The eslint-disable-next-line is needed because the analysis doesn't
seem to understand the non-static string.
The return was split into a separate line because that made eslint
complain that we needed to be consistent about returns, though
the return type of defineModuleGetter is undefined.
Finally, I updated the ChromeUtils.import() calls so they weren't using
the deprecated argument.
Differential Revision: https://phabricator.services.mozilla.com/D158506
This used to be needed to improve the debugging information, but isn't any more.
I fixed up the whitespace at the same time to match what the automated formatter
would have done in the next patch, to reduce gratuitous churn.
Differential Revision: https://phabricator.services.mozilla.com/D158970
I removed test_bug596580.xhtml because it is testing JS versioning for
the subscript loader, which is long gone.
This adds XPCNativeWrapper as a valid global object. It is already allowed
for the other two kinds of mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D158504
Also change .eslintignore to cover the other directories.
This also fixes the indentation the automatic fixer messed up in a few XHTML files.
Differential Revision: https://phabricator.services.mozilla.com/D158503
The eslint autofixer makes URLs that appear in strings in JS into https://
URLs. However, it does not change any URLs in the HTML part of the tests, which
caused some tests to fail. To try to ensure that the autofixer didn't break
tests in any way that doesn't show up as a failure, I did a light audit of the
tests. Specifically, I looked at files in js/xpconnect/tests/chrome/ containing
the string "example." in a URL string in more than one place. I switched these
URLs over to https://, both in JS and HTML.
I left alone test_secureContexts.html, which uses an http:// URL in HTML, but
is clearly trying to test http://.
I did a similar check for mochi.test but there weren't any tests that used it
more than once.
The tests that originally were broken by the autofix were:
* test_evalInWindow.xhtml
* test_expandosharing.xhtml
* test_wrappers.xhtml
* test_xrayic.xhtml
My audit didn't find any other instances that looked like they might fail. I
did fix a few other places, but I think in those cases the HTML and JS URLs were
cross origin anyways so it shouldn't really matter if one is https:// and the
other is http://.
I also changed single quotes to double quotes for the URLs I changed, because
the autofix is going to do that anyways.
Differential Revision: https://phabricator.services.mozilla.com/D158502
We didn't close gfxconfig and the device manager properly before, which
causes a leak.
Also, using `mKind` to store the kind in the beginning helps us not need
to call `UtilityProcessChild::GetSingleton()` again to check the type,
which would also cause leaking and that would be addressed in bug 1792952.
Depends on D158072
Differential Revision: https://phabricator.services.mozilla.com/D158386
This patch moves some media source's methods to the manager thread to
avoid deadlock. Eg. in previous threading model, media source calls the
engine stream's `NotifyEndOfStream()` and requires a lock. But inside
that function, it would check media source's state, which also requires
a lock. So the deadlock happened.
Now we want to make the media source run most of its methods on either
the manager thread, or the mf thread pool. We leave the task queue for
the media engine streams.
In addition, we also remove the `IsEnded()` method from the engine
stream's public interface to avoid completed accessing across threads.
Now the media source will only rely on the engine stream's ended event.
If the source gets started again after the streams are ended, we
guarantee that streams will send corresponding ended events again in
order to let the media engine know the playback end.
Depends on D157992
Differential Revision: https://phabricator.services.mozilla.com/D158072
One case I discovered is that
- call MFMediaSource::NotifyEndOfStream() on the manager thread (it dispatches a task to task queue)
- call MFMediaSource::Shutdown on the manager thread
Then when `MFMediaSource::NotifyEndOfStreamInternal` is running on the
task queue, the stream we're accessing might be released in the shutdown
process on the manager thread, which causes the access-violation.
Depends on D157991
Differential Revision: https://phabricator.services.mozilla.com/D157992
When accumulating statistic data from the media engine. we guarantee the
data increases monotonically [1]. It's incorrect to use `GetDroppedFrames()`
because it could include other stages data which are not controlled by
the media engine, and causes the incorrect result.
Each stage of dropped frame should be calculated separately.
Eg. media engine doesn't drop any frame (0), but the format reader drops
1 decoded frame, which results in accumulating (0 - 1) frame to `mFrameStats`.
[1] https://searchfox.org/mozilla-central/rev/52da19becaa3805e7f64088e91e9dade7dec43c8/dom/media/ipc/MFMediaEngineParent.cpp#549-560
Depends on D157883
Differential Revision: https://phabricator.services.mozilla.com/D157884
Using mutex can solve the following issues.
1. Racing between `MFMediaSource::Shutdown()` and other media source's functions running on the mf thread pool.
I originally thought the media engine would call media source's shutdown
on the mf thread pool, but I was wrong. The media engine would call that
method on the thread where we called the media engine's function.
Therefore, when we call `mediaEngine->shutdown()` on the manager thread,
it would also trigger the source's shutdown on the same thread. There
are also some other sources' methods would be executed on the manager
thread by this kind of calls as well.
This situation causes a race, we're shutting down the media stream on
the manager thread, and are still using them on the mf thread pool.
2. Media stream doesn't rely pending media engine's sample request properly
In [1], after a stream starts, it would check if there is any pending
request we need to reply. And that will check this condition [2] to
determine if we should do that.
That is a racing as well. Because at the time the stream checks the
source's state, the source might be still running media source's start
function and haven't changed its status [3] yet. That causes stream not
to reply on pending requests and we also don't have other chances to
reply that, resulting in the playback stalled.
[1] https://searchfox.org/mozilla-central/rev/52da19becaa3805e7f64088e91e9dade7dec43c8/dom/media/platforms/wmf/MFMediaEngineStream.cpp#183-185
[2] https://searchfox.org/mozilla-central/rev/52da19becaa3805e7f64088e91e9dade7dec43c8/dom/media/platforms/wmf/MFMediaEngineStream.cpp#314-317
[3] https://searchfox.org/mozilla-central/rev/52da19becaa3805e7f64088e91e9dade7dec43c8/dom/media/platforms/wmf/MFMediaSource.cpp#194
Depends on D157882
Differential Revision: https://phabricator.services.mozilla.com/D157883
This patch attempts to read color primary information from platform
agnostic decoders. It doesn't use any of this information to change how
the video frame is displayed.
It also cleans up some VPX transfer characteristics, to ensure they are
actually retrieved from the codec information, when available.
Differential Revision: https://phabricator.services.mozilla.com/D156362
If an external image shows up multiple times while using a different image rendering
setting on each instance, we can erroneously call handler.lock() for each instance in
parallel, thus defaulting to the last image rendering setting supplied for all instances
in that batch.
To work around this, we get rid of the concept of having RenderTextureHosts maintain and
set the image rendering state, which results in a nice simplification. Then, when we go
to actually bind an external image inside WebRender, we set the image rendering state
at that point, so that regardless of how many instances of an external image are locked
simultaneously, we always use the correct image rendering setting for a batch.
Differential Revision: https://phabricator.services.mozilla.com/D158920
Behavior of an editor with only a table seems the same before and after
this patch when positioning the caret with keyboard or mouse, which
seems what this was about (see bug 34356). Nobody reads the magic return
value either, so remove it as well.
If we wanted to tweak this, there's no reason to special-case tables
(we'd want to allow positioning in any arbitrary line-iterable frame).
Differential Revision: https://phabricator.services.mozilla.com/D158927
It's not clear what the advantage of waitFor is supposed to be, but in
practice the use of requestAnimationFrame makes the timing somewhat
unpredictable. Just using the built-in timer based polling seems
simpler for these tests without changing their behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D158967
If there's something I'm missing here that's totally fine, I just keep making
this change locally and reverting it and it would be convenient to just leave
it.
Differential Revision: https://phabricator.services.mozilla.com/D158038
