As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.
As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.
Hitting the button will set the new pref to 'true' and reload the page.
Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).
The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.
Differential Revision: https://phabricator.services.mozilla.com/D45799
--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
This patch adds fullscreen and windowed youtube tests for the V9 and H264 encoding at 1080p30 and 1080p60. Each subtest runs for 20 page cycles which amounts to about 5 minutes each. It also begins adding these to power test tasks running on the macosx-1014 reference hardware.
Differential Revision: https://phabricator.services.mozilla.com/D45067
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
The request is used to track if the promise is resolved or not, so we should call its `Complete()` method once promise is resolved, in order to keep the state of the request correct.
Differential Revision: https://phabricator.services.mozilla.com/D47331
--HG--
extra : moz-landing-system : lando
This changes certain fission tests to run tier 1 and start running on integration branches:
linux64-qr/debug mochitest-plain
linux64-qr/debug mochitest-media
linux64-qr/debug mochitest-webgl*
linux64/debug browser-chrome
All other fission tests continue to run as tier 2.
Differential Revision: https://phabricator.services.mozilla.com/D47295
--HG--
extra : moz-landing-system : lando
Now all test cases for individual transform properties work fine on GeckoView.
Depends on D47200
Differential Revision: https://phabricator.services.mozilla.com/D47201
--HG--
extra : moz-landing-system : lando
I think these should hold, everything that runs under them should just schedule
other stuff to some later date:
* Synth mouse events -> scheduled as refresh driver observers.
* Scroll events -> Scheduled as well.
* Caret state change events -> Also scheduled after last patch.
* IME and accessibility stuff -> I don't think they can reenter layout.
We can always revert this if it causes troubles, plus it shouldn't crash on
release so should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D31090
--HG--
extra : moz-landing-system : lando
Instead, post the event for the next turn of the event loop.
In this case, what killed the frame is ActionBarHandler.jsm via
Selection.toString().
Depends on D31088
Differential Revision: https://phabricator.services.mozilla.com/D31089
--HG--
extra : moz-landing-system : lando
Since background threads get shut down near `xpcom-shutdown-threads`,
there's no need to have `WebCryptoThreadPool` anymore; we can rely on
the background thread dispatching to fail to dispatch our task as
appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D47006
--HG--
extra : moz-landing-system : lando
This will raise the high water mark of a parse, because we hold onto a copy of
the CharBuffer. There's a hard upper limit of the memory increase possible of
2x, where the parse consists almost entirely of BigInt literals, but,
nevertheless, this could be impactful on code that uses BigInt literals
extensively.
This patch also teaches FoldConstants how to tell if a BigInt is zero
without allocating the actual BigInt.
Differential Revision: https://phabricator.services.mozilla.com/D45256
--HG--
extra : moz-landing-system : lando
It's nicer to have everything in one place, and because we support
clang-cl, we can have a single definition for the error flag too.
Differential Revision: https://phabricator.services.mozilla.com/D45705
--HG--
extra : moz-landing-system : lando
