P2 changed the way the H264Converter would be calling the decoder. The assumption in the EMEDecryptor was pretty incorrect to start with.
Depends on D7865
Differential Revision: https://phabricator.services.mozilla.com/D7882
--HG--
extra : moz-landing-system : lando
When used with the LowLatency option, we guarantee that the stream will contain no B-frame, as such we can reduce the re-ordering queue to zero. The apple VT decoder already returns frames in decode order making this change trivial.
Depends on D7861
Differential Revision: https://phabricator.services.mozilla.com/D7862
--HG--
extra : moz-landing-system : lando
The H264Converter can be used on a thread that isn't a nsThread or a TaskQueue, so having the H264Converter dispatching tasks isn't going to work
So instead we run all the code on the decoder's taskqueue using promise chaining.
All internal methods are made to assert that they are running on the task queue accordingly
Depends on D7860
Differential Revision: https://phabricator.services.mozilla.com/D7861
--HG--
extra : moz-landing-system : lando
I thought it was going to be trivial to add a test-case for this with a scale
transform and such, but I haven't been able to.
This restores the wallpaper that there was before my change.
Differential Revision: https://phabricator.services.mozilla.com/D8000
--HG--
extra : moz-landing-system : lando
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
Summary:
The fix of bug 1479964 breaks some web apps using Google Closure including
Google's apps. So, for Nightly testers, we should disable the new behavior
until Google Closure fixes it or we can disable the new behavior per web apps.
Reviewers: smaug
Reviewed By: smaug
Bug #: 1497546
Differential Revision: https://phabricator.services.mozilla.com/D8090
--HG--
extra : histedit_source : 03f59268c220297040c1c5186e62a05710d468b9
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
gfritzsche asked me to use this method to add compatibility to measure the time in seconds.
At the moment we are forced to clone `devtools/client/shared/TelemetryStopwatch.jsm` so that we can get it working the way we need.
The problem is that it measure time in ms when using start() finish() etc. and that creates too many entries in our charts and makes them next to impossible to read.
It would be much better if we could measure the time in seconds instead.
Differential Revision: https://phabricator.services.mozilla.com/D4936
--HG--
extra : moz-landing-system : lando
Now that xpcshell no longer uses ParentProcessTargetActor, we can remove comments about it using it.
We can also remove a couple of null checks against docShell that were specific to this usecase.
MozReview-Commit-ID: 67sugv4bZC3
Depends on D7416
Differential Revision: https://phabricator.services.mozilla.com/D7726
--HG--
extra : moz-landing-system : lando
Fix a bug that the current MediaRecorder's state error cases does not match the W3C spec.
pause() and resume() should throw an INVAILD_STATE_ERR only when it is inactive state, making them
independant.
Simply changing if statements is enough because the underlying encoder object (TrackEncoder) will
ignore Suspend/Resume calls when it is already suspended/recording so there won't be side-effects by
multiple pause()/resume() calls.
Differential Revision: https://phabricator.services.mozilla.com/D7910
--HG--
extra : moz-landing-system : lando
Jean-Yves Avenard
Emilio Cobos Álvarez
Kartikaya Gupta
Daniel Holbert
Mike Hommey
David Walsh
Gurzau Raul
Eric Faust
Manuel Rego Casasnovas
Bogdan Tara
Sebastian Hengst
Gabriel Luong
Masayuki Nakano
shindli
Chris Manchester
Narcis Beleuzu
Dão Gottwald
Jan Horak
Michael Ratcliffe
yulia
Alexandre Poirot
Johann Hofmann
Daisuke Akatsuka
Alessio Placitelli
Nazım Can Altınova
vinoth
Haik Aftandilian
Bumsik Kim