When we create a video decoder with ffmpeg, we check if the underlying
decoder implementation is supplied by OpenH264. If so, and the
media.ffmpeg.allow-openh264 is set to false (the default), we refuse to
create the video decoder. This is a problem because the decoder module
for ffmpeg declared support for H264, so we did not try falling back to
our own OpenH264 plugin exposed via GMP.
This patch duplicates the logic check for ffmpeg + OpenH264 in
FFmpegDecoderModule::Supports to ensure we fallback properly.
Differential Revision: https://phabricator.services.mozilla.com/D223843
If a canvas never stops drawing to the point the canvas does not go
dormant to free buffers, and the caller never does a readback to create
a checkpoint, then we may never release our hold on resources used
earlier in the recording. This patch makes it so that we check at the
end of each transaction. Eventually the playback of the recording will
catch up, or the recording will go dormant, and we will release the
relevant surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D223572
Bug 1915433 made this perma because it caused gfxPlatform initialization
(thus a bit more work), where before it used to be skipped by a pref.
But this happened intermittently before my patch, so likely this just
pushed the test over the limit...
Given the amount of tests skipped here on tsan, maybe we should have a
higher xpcshell timeout there?
The logic should be equivalent when frame IDs on aImages are contiguously
increasing from IDs on previously set frames.
There are currently no callers passing empty aImages, but the logic in this
case would now be as described in the documentation of
UpdatePrincipalHandleForFrameID():
> We will notify mElement that aPrincipalHandle has been applied when all
> FrameIDs prior to aFrameID have been flushed out.
Original Revision: https://phabricator.services.mozilla.com/D223922
Differential Revision: https://phabricator.services.mozilla.com/D224435
This avoids a deprecation message getting logged when the webRTC code expects
the configuration of the ICE server instead.
Bug 1921991 had updated the package.
Thunderbird would like to enable the `app.update.langpack.enabled` pref
globally in its main preference file `/comm/mail/app/profile/all-thunderbird.js`,
similar to what Firefox is doing already in its counterpart file
`/browser/app/profile/firefox.js` ([here](https://searchfox.org/mozilla-central/source/browser/app/profile/firefox.js#168)).
However, if we do that, the following toolkit test starts to fail:
/toolkit/mozapps/update/tests/unit_aus_update/disableBackgroundUpdatesNonBackgroundTask.js
The reason is that the test ignores global preferences for Firefox, but
not for Thunderbird. This is due to bug 1168178 and bug 755724: Firefox
does not load its global preferences unless the manifest specifically
requests it by specifying `firefox-appdir = browser`.
The test which fails needs `app.update.langpack.enabled` to be unset or
false.
Differential Revision: https://phabricator.services.mozilla.com/D223927
The test was timing out, possibly because the confirmation interval could go
up to 64 seconds, while the test was only waiting for 60 seconds.
Adding a pref lets us reduce the time it takes to run the test, while
also making sure that the at least one successful attempt can execute
before the waiting time is done.
Differential Revision: https://phabricator.services.mozilla.com/D223090
The BrowserChild should only be cleared on EndDragSession, which is sent when
the user finishes or cancels dragging. This is reciprocal to it being set in
StartDragSession.
The change to nsDragSessionProxy::EndDragSessionImpl is non-functional -- it
highlights the BrowserChild symmetry above.
Original Revision: https://phabricator.services.mozilla.com/D222389
Differential Revision: https://phabricator.services.mozilla.com/D222947
Debian's firefox-esr package adds its own /usr/bin/firefox and diverts
it away, so we either need to do the same or clean up the diversion in
our postinst, otherwise /usr/bin/firefox goes permanently missing when
upgrading from Debian to Mozilla's firefox-esr package.
Original Revision: https://phabricator.services.mozilla.com/D222752
Differential Revision: https://phabricator.services.mozilla.com/D222916
The console notification is only created when an error page would not
otherwise load, so allows us to detect the situation where the error
page is not going to be loaded.
Differential Revision: https://phabricator.services.mozilla.com/D218984
This patch corrects a few different issues related to recycling
MacIOSurface objects.
1) When recycling a surface, we must check that the cached surfaces
match all of the requested parameters, not just the size. If we do
not, we should just flush the whole cache immediately since they
should all be created with the same parameters.
2) Allocations can fail, and we should check for failing to get a
surface from the allocator and fall back if so.
3) Locking can fail, and we should check that return value at all of the
call sites.
This may help resolve a number of otherwise difficult to understand
crash signatures. It may also solve display corruption issues in rare
cases where the parameters that changed were roughly equivalent such
that everything appears to work, but they differ enough to change the
presentation.
Differential Revision: https://phabricator.services.mozilla.com/D222775
