The intent of adding this pref is to allow us to change defaults for
security.tls.version.min for a progressive rollout of a TLS 1.0 and 1.1
deprecation. During that process, we'd like to offer the option to enable these
old TLS versions, without adding a pref override that would cause those versions
to remain enabled once we finish the rollout.
Those people who have triggered the override will be able to access TLS 1.0 and
1.1 sites until we eventually remove the code that respects this pref. What is
likely to happen is that this pref will remain in code past the end of our
rollout for part of a release cycle, plus maybe the next cycle depending on
how timing works out.
This pref is a simple boolean that we'll remove in March 2020.
Differential Revision: https://phabricator.services.mozilla.com/D45798
--HG--
extra : moz-landing-system : lando
This flips the default for security.tls.version.min to 3 (TLS 1.2) for the
Nightly channel.
Having had this pref at this level for the last year, I can confirm that this
does break the occasional site, but it is quite rare. The intent of this change
is to start making it more obvious when sites don't support TLS 1.2.
I'm asking for wider review because this is a disruptive change.
Differential Revision: https://phabricator.services.mozilla.com/D45627
--HG--
extra : moz-landing-system : lando
The intent of adding this pref is to allow us to change defaults for
security.tls.version.min for a progressive rollout of a TLS 1.0 and 1.1
deprecation. During that process, we'd like to offer the option to enable these
old TLS versions, without adding a pref override that would cause those versions
to remain enabled once we finish the rollout.
Those people who have triggered the override will be able to access TLS 1.0 and
1.1 sites until we eventually remove the code that respects this pref. What is
likely to happen is that this pref will remain in code past the end of our
rollout for part of a release cycle, plus maybe the next cycle depending on
how timing works out.
This pref is a simple boolean that we'll remove in March 2020.
Differential Revision: https://phabricator.services.mozilla.com/D45798
--HG--
extra : moz-landing-system : lando
This flips the default for security.tls.version.min to 3 (TLS 1.2) for the
Nightly channel.
Having had this pref at this level for the last year, I can confirm that this
does break the occasional site, but it is quite rare. The intent of this change
is to start making it more obvious when sites don't support TLS 1.2.
I'm asking for wider review because this is a disruptive change.
Differential Revision: https://phabricator.services.mozilla.com/D45627
--HG--
extra : moz-landing-system : lando
I think most of them should not be needed after bug 1561450. From our discussion
at TPAC in https://github.com/w3c/csswg-drafts/issues/4239, there should be no
reason not to do this unless we find fallout.
We need to enable the pref in tests that test these particular heuristics of
course.
Differential Revision: https://phabricator.services.mozilla.com/D47315
--HG--
extra : moz-landing-system : lando
Intent to unship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/JnJVGTmIwPE
- Introduce a new preference option mathml.deprecated_alignment_attributes.disabled()
to disable alignment attributes for mfrac/munder/mover/munderover elements.
- Disable the attributes in Nightly and when running WPT tests.
- Enable the attributes in other channels but add a counter and deprecation warning.
- Remove failure expectation for WPT test frac-numalign-denomalign-001.html for mfrac
- Add new WPT test for underover-legacy-align-attribute-001.html for munder/mover/munderover
- Enable the attributes for MathML reftests checking these attributes.
- Disable numalign/denomalign test for Mochitest test_bug975681.html when the attributes
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D46712
--HG--
extra : moz-landing-system : lando
This approach does have some stacking issues. The way to fix this would
be to instrument the brush_image shader rather than adding debug rects.
Something like: #ifdef WR_FEATURE_SFW frag.color = vec4(0,1,1,1); #endif
That's slightly more involved though, so I'm going to leave it for now.
Differential Revision: https://phabricator.services.mozilla.com/D47155
--HG--
extra : moz-landing-system : lando
In bug 1565689, we have implemented new an audio focus management, which allows us to address audio competition even if those audio happens on different processes.
We can try to enable this new mechanism on Android Nightly first, where we have enabled managing audio competition by default.
Differential Revision: https://phabricator.services.mozilla.com/D46636
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
* Let layout.css.use-counters.enabled be independent from the unimplemented
property counters.
* Always count in the style system (that is, always create
Document::mStyleUseCounters), so that the warning from bug 1582374 works
irrespective of these prefs.
* Add a pref check to the SVGElement code path so that the prefs properly
reflect whether the histograms end up being recorded or not.
* Make the pref checks consistent (check both when reporting telemetry, not
earlier).
Differential Revision: https://phabricator.services.mozilla.com/D46633
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
Removes the duplicate media.wmf.* prefs from `all.js`. Defaults to `all.js` values in Static Prefs where needed.
Differential Revision: https://phabricator.services.mozilla.com/D46342
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
This is in the interests of allowing the frontend team to experiment with
switching from XUL grid to CSS grid, without inadvertently changing the
display values for the grid items via css-grid-item blockification.
This patch's new pref is not expected to remain in the codebase for long.
We're just adding it so that the behavior remains the same by default, because
we do currently have some XUL code that inadvertently depends on -moz-box
display values being blockified to 'block'. The plan is for folks to remove
that dependency e.g. by adding explicit 'display:block' styling to frontend
code as-needed. After we've done that, we can tentatively flip the pref to true
by default, and then remove the pref entirely.
Differential Revision: https://phabricator.services.mozilla.com/D45258
--HG--
extra : moz-landing-system : lando
When mozAddonManager isn't available, AMO installs extensions through a different code
path that involves downloading the XPI from addons.cdn.mozilla.net and routing through
amContentHandler.jsm
That code breaks when addons.cdn.mozilla.net is in a separate process. So we put it into
the privileged mozilla web content process. Admittedly this isn't used in 99.99% of cases.
Differential Revision: https://phabricator.services.mozilla.com/D33677
--HG--
extra : moz-landing-system : lando
properties-db.js is patched via `./mach devtools-css-db` after flipping
column-span pref to @IS_NIGHTLY_BUILD@ in StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D41461
--HG--
extra : moz-landing-system : lando