According to mstriemer, when we want to use Lit in mozilla-central,
including in Storybook stories, this is how we want to import it now
that the Lit package has been removed from Storybook as of bug 1803151.
Differential Revision: https://phabricator.services.mozilla.com/D167611
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
view-timeline shorthand includes view-timeline-name and
view-timeline-axis, but excludes view-timeline-inset.
Note: We will fix the test of "view-timeline-name: auto" in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D166404
view-timeline-name: `none | <custom-ident>#`
view-timeline-axis: `[ block | inline | vertical | horizontal ]#`
Note:
Both view-timeline-name and scroll-timeline-name should accept `auto`.
We will fix it in this patch series.
Differential Revision: https://phabricator.services.mozilla.com/D166242
When prepping the moz-libwebrtc repo, it makes sense to reset all the no-op
tracking files and the resume_state file for the new fast-forward session.
Differential Revision: https://phabricator.services.mozilla.com/D166497
- automatically create state directory (.moz-fast-forward) under top level or repo if missing
- automatically create log and tmp subdirectories if missing
- only execute use_config_env.sh once in nested scripts
- move default location for config_env under state directory
Differential Revision: https://phabricator.services.mozilla.com/D166492
This is a requirement of the FedCM spec.
Requesting review from you because I believe you are the only other person actively working on Credential Management API things and this touches the `navigator.credentials` object implementation.
Differential Revision: https://phabricator.services.mozilla.com/D167157
This removes checks to the well-known file.
This makes having more than one folder of tests possible.
I'm leaving the mochitests that excercise the platform code as the folder that tests well-known behavior.
Differential Revision: https://phabricator.services.mozilla.com/D167391
This is an side-effect of PFetch implementation.
Currently, PFetch is only default on nightly, so when running merging to Beta, the test will fail.
Differential Revision: https://phabricator.services.mozilla.com/D167523
We haven't decided where the CDM proxy is going to be created and
passed, for now let's assume the media engine parent is the entry point
to set the CDM proxy to the content protection manager and the media
source.
Depends on D167329
Differential Revision: https://phabricator.services.mozilla.com/D167441
The content protection manager needs to perform some tasks on the CDM,
we wrapped the CDM and expose a proxy class in order to let other
components interact with it.
Differential Revision: https://phabricator.services.mozilla.com/D167305
After adding more files, `WMFEncoderModule.cpp` is no longer in the same
unify build unit with the `WMFMediaDataEncoder.cpp`. Therefore, we need
to make the implementation of template class `WMFMediaDataEncoder`
visible in the header file, otherwise the compiler would report link
error of undefined `WMFMediaDataEncoder` symbol.
Differential Revision: https://phabricator.services.mozilla.com/D167304
