For media engine playback, we would like to let ExternalStateMachine
being aware of the CDM proxy, so that it can pass the the Id of MFCDM
actor to the remote media engine via MFMediaEngineChild in following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D171800
For a few NDK releases now, the situation has been simplified wrt
headers and libraries, and while we're currently still using things here
and there because we never changed our ways, we can simplify things a
lot by using the new simplified things. This involves:
- Using a --target that contains the Android version, making clang set
__ANDROID_API__ itself, and makes it look in $sysroot/usr/lib/$target/$ver
when linking.
- Using the sysroot that is under toolchains/llvm/prebuilt/*.
- Removing the hacks around libstdc++/libc++.
This ends up emptying stlport compiler flags, which allows to remove a
bunch of things.
Differential Revision: https://phabricator.services.mozilla.com/D172039
Notably, this also updates the em ratio of the "base" font size and the deemphasized font-size.
In the Figma specification, the base font size is 13px, and the deemphasized font-size is 10px,
which is ~84% of 13px.
Differential Revision: https://phabricator.services.mozilla.com/D172443
StaticPrefs don't increment ACCESS_COUNTS, so switching from GetPref to
StaticPrefs, while a perf and best-practice win, causes this test to
fail because the test sees no accesses recorded for this pref.
See bug 1818130 for details.
Differential Revision: https://phabricator.services.mozilla.com/D170554
Mingw's dcomp.h is not the official one, but rather a by-hand
reproduction. While this newly-updated version has e.g.
IDCompositionFilterEffect, it is still missing e.g.
IDCompositionColorMatrixEffect.
Differential Revision: https://phabricator.services.mozilla.com/D168839
+ 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
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
This is mostly just switching the upstream tasks with pull the Windows installers from. The only wrinkle is that we're not attributing the asan-reporter installers (and we shouldn't IMO), so I had to add support for keying upstream tasks on platform in the beetmover manifests. (If we simply listed all three possible upstreams, we ended up pulling _two_ installers for platforms that are attributed...and I don't even know which one would get published, or if both would.)
Differential Revision: https://phabricator.services.mozilla.com/D170246
The kind is more or less the same as the en-US counterpart in the previous revision.
As with the en-US attribution kind, this also does does _not_ use the `multi_dep` loader to set up the per-locale tasks. Of course, we do need to split by locale, which is now being done quite explicitly by the new `split_by_locale` that looks at the specified locales file, and uses specific platforms specified in the kind. As with the previous revision, please feel free to push back if any of you feel any of this is going in the wrong direction, is worse than multi_dep, etc. etc.
Differential Revision: https://phabricator.services.mozilla.com/D170245
Notably, the actual attribution code we're using is stored in `browser`. This was largely motivated by the fact that the subsequent revision in this stack will also need it, and this seemed like the best way to make it shareable between the two. The only alternative I could come up with was stuffing it into a transforms - but it's really just data - there's no reason it ought to live in such a place. (We do have precedent for this sort of thing with both locale and whats new page information, so I don't think it's breaking huge new ground.) Nick - I'm tagging you mainly on this part, but I welcome any other comments you may have (here or in the rest of the stack for that matter).
The other notable part of this patch is that I've _explicitly_ decided not to use the `multi_dep` loader, nor reimplement any of its magic pulling of properties in a transform. I find that this makes it more clear what's _actually_ going on, and easier to debug when making changes. The dwonside, of course, is that there's some verboseness in the kind - all platforms we need to run this for must be explicitly listed. I'm open to debate on whether or not this is the right trade-off, so feel free to push back if you disagree.
Differential Revision: https://phabricator.services.mozilla.com/D170243
We've decided to use a new attribution field when attributing our vanilla builds. This field is valid as the _only_ field in the attribution data.
Differential Revision: https://phabricator.services.mozilla.com/D171592
This allows us to easily append attributions, which is helpful when configuring this script in taskgraph. (You can set up some defaults, and then add others for specific jobs.)
As far as I can tell, all current usage of this script uses the environment variables, so it should be safe to remove the current arguments.
Differential Revision: https://phabricator.services.mozilla.com/D170240
There's actually nothing partner-specific in this script, and it's about to be used for other types of attribution as well.
Differential Revision: https://phabricator.services.mozilla.com/D170239
If one of them are removed from the DOM tree, it's hard to keep handling it
since we have both split direction paths. Therefore, let's just return error
but not throw new exception in the case.
Differential Revision: https://phabricator.services.mozilla.com/D172205
The root cause of this bug is, we tried to compute new offset with offset at
the new node. However, as explained in the inline comments, it should compute
the offset with the right node offset in the new mode. Therefore, it needs
to handle it by itself instead of just calling `SelAdjInsertNode`.
Differential Revision: https://phabricator.services.mozilla.com/D171965
