Bug 1501657 - Move early betas to use the strict list for the default cookie restrictions r=francois

Differential Revision: https://phabricator.services.mozilla.com/D9657

--HG--
extra : moz-landing-system : lando

Now that the VRService thread is enabled by default, we
can remove these old files.

The OpenVR 3rd party code has been moved from gfx/vr/openvr
to gfx/vr/service/openvr to be closer to the OpenVRSession
implementation.

The Oculus header (ovr_capi_dynamic.h) has been moved from
gfx/vr/ovr_capi_dynamic.h to gfx/vr/service/oculus to be
closer to the OculusSession implementation.

Differential Revision: https://phabricator.services.mozilla.com/D9600

--HG--
rename : gfx/vr/ovr_capi_dynamic.h => gfx/vr/service/oculus/ovr_capi_dynamic.h
rename : gfx/vr/openvr/LICENSE => gfx/vr/service/openvr/LICENSE
rename : gfx/vr/openvr/README.md => gfx/vr/service/openvr/README.md
rename : gfx/vr/openvr/README.mozilla => gfx/vr/service/openvr/README.mozilla
rename : gfx/vr/openvr/headers/openvr.h => gfx/vr/service/openvr/headers/openvr.h
rename : gfx/vr/openvr/moz.build => gfx/vr/service/openvr/moz.build
rename : gfx/vr/openvr/src/README => gfx/vr/service/openvr/src/README
rename : gfx/vr/openvr/src/dirtools_public.cpp => gfx/vr/service/openvr/src/dirtools_public.cpp
rename : gfx/vr/openvr/src/dirtools_public.h => gfx/vr/service/openvr/src/dirtools_public.h
rename : gfx/vr/openvr/src/envvartools_public.cpp => gfx/vr/service/openvr/src/envvartools_public.cpp
rename : gfx/vr/openvr/src/envvartools_public.h => gfx/vr/service/openvr/src/envvartools_public.h
rename : gfx/vr/openvr/src/hmderrors_public.cpp => gfx/vr/service/openvr/src/hmderrors_public.cpp
rename : gfx/vr/openvr/src/hmderrors_public.h => gfx/vr/service/openvr/src/hmderrors_public.h
rename : gfx/vr/openvr/src/ivrclientcore.h => gfx/vr/service/openvr/src/ivrclientcore.h
rename : gfx/vr/openvr/src/openvr_api_public.cpp => gfx/vr/service/openvr/src/openvr_api_public.cpp
rename : gfx/vr/openvr/src/pathtools_public.cpp => gfx/vr/service/openvr/src/pathtools_public.cpp
rename : gfx/vr/openvr/src/pathtools_public.h => gfx/vr/service/openvr/src/pathtools_public.h
rename : gfx/vr/openvr/src/sharedlibtools_public.cpp => gfx/vr/service/openvr/src/sharedlibtools_public.cpp
rename : gfx/vr/openvr/src/sharedlibtools_public.h => gfx/vr/service/openvr/src/sharedlibtools_public.h
rename : gfx/vr/openvr/src/strtools_public.cpp => gfx/vr/service/openvr/src/strtools_public.cpp
rename : gfx/vr/openvr/src/strtools_public.h => gfx/vr/service/openvr/src/strtools_public.h
rename : gfx/vr/openvr/src/vrpathregistry_public.cpp => gfx/vr/service/openvr/src/vrpathregistry_public.cpp
rename : gfx/vr/openvr/src/vrpathregistry_public.h => gfx/vr/service/openvr/src/vrpathregistry_public.h
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D9719

--HG--
extra : moz-landing-system : lando

Android xpcshell tests run `elfhack -r`, and do so by using an
elfhack binary from an archive downloaded via tooltool (which contains
other things).

Instead, we just put the elfhack binary in the
target.common.tests.tar.gz archive, and make the xpcshell harness
use it from there instead, allowing to pick in-tree changes to elfhack.

Depends on D9623

Differential Revision: https://phabricator.services.mozilla.com/D9624

--HG--
extra : moz-landing-system : lando

Bug 1499915 - Support undoing elfhack when the elfhacked sections are in separate segments r=froydnj

This is some sort of followup to bug 1423813, providing a minimalistic
way to undo elfhack when the elfhack sections are in separate segments,
which has been the case since bug 1385783 but didn't cause problems
on Android builds until bug 1423822.

Depends on D9622

Differential Revision: https://phabricator.services.mozilla.com/D9623

--HG--
extra : moz-landing-system : lando

This effectively backs out bug 822584, which worked around a similar
problem to what we are facing with Android xpcshell, being that the
crash reporter doesn't handle the address space "fragmentation" induced
by elfhack. The work around worked, at the expense of some added
complexity.

It was used for B2G only, and has effectively been unused since B2G was
retired.

Differential Revision: https://phabricator.services.mozilla.com/D9622

--HG--
extra : moz-landing-system : lando

I guess we can eventually replace the conditions for autoSize with
`width == nsViewportInfo::Auto` or `height == nsViewportInfo::Auto`, but it
will break current behavior so for now we are going to preserve the current
behavior.  For example, we currently consider no viewport meta tag means
autoSize is disabled but it should be an autoSize case.

Depends on D9461

Differential Revision: https://phabricator.services.mozilla.com/D9462

--HG--
extra : moz-landing-system : lando

Following four conditions are where nsIDocument::mAutoSize is true and
test cases for each condition. The conditions are the cases where we
currently set nsIDocument::mAutoSize true in nsIDocument:GetViewportInfo.

1) width=device-width
  test_meta_viewport_auto_size_by_device_width.html
2) no width && height=device-height
  test_meta_viewport_auto_size_by_device_height.html
3) no width && initial-scale=1
  test_meta_viewport_auto_size_by_fixed_height_and_initial_scale_1.html
  test_meta_viewport_auto_size_by_initial_scale_1.html
4) invalid width && (invalid height || no height)
  test_meta_viewport_auto_size_by_invalid_width.html

Below tests are cases that autoSize is disabled.
  test_meta_viewport_auto_size_by_fixed_width_and_initial_scale_1.html
  test_meta_viewport_auto_size_by_fixed_width_and_device_height.html
  test_meta_viewport_auto_size_by_initial_scale_0_5.html
  test_meta_viewport_auto_size_by_invalid_width_and_fixed_height.html

Depends on D9460

Differential Revision: https://phabricator.services.mozilla.com/D9461

--HG--
extra : moz-landing-system : lando

This is a follow-up fix for bug 1431601, I didn't notice that we constrain
mMaxZoom in here nsViewport class.
In bug 1431601, instead we did constrain the value in nsIDocument::GetViewportInfo
since the contrained value is used in the function.

Differential Revision: https://phabricator.services.mozilla.com/D9459

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D9263

--HG--
rename : testing/web-platform/meta/beacon/beacon-error.window.js.ini => testing/web-platform/meta/beacon/beacon-error.sub.window.js.ini
rename : testing/web-platform/tests/beacon/beacon-error.window.js => testing/web-platform/tests/beacon/beacon-error.sub.window.js
extra : moz-landing-system : lando

Bug 1488011 - Set the checkbox label instead of using an adjacent XUL label so the checkbox focus ring appears correctly. r=MattN

Differential Revision: https://phabricator.services.mozilla.com/D9708

--HG--
extra : moz-landing-system : lando

Fixes test browser/base/content/test/general/browser_documentnavigation.js
for browser.xhtml.

Differential Revision: https://phabricator.services.mozilla.com/D9711

--HG--
extra : moz-landing-system : lando

This combines some of your ideas from D8074, in which I think is quite a big improvement to the overall code.

The code for nsTransferable::GetTransferData, especially nsIFlavorDataProvider is a bit wonky, because I tried to preserve the current behavior.

Differential Revision: https://phabricator.services.mozilla.com/D9599

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D9423

--HG--
extra : moz-landing-system : lando

Backed out changeset 4b5b1ff23dd7 (bug 1372157) for failing at webgl-conf/generated/test_2_conformance2__vertex_arrays__vertex-array-object.html on a CLOSED TREE

Depends on D9661

Differential Revision: https://phabricator.services.mozilla.com/D9662

--HG--
extra : moz-landing-system : lando

Bug 1501662 - Add more .eslintrc.js files for test directories (dom, modules, netwerk and parser). r=mossop

Differential Revision: https://phabricator.services.mozilla.com/D9661

--HG--
extra : moz-landing-system : lando

The previous resolution is restored when exiting fullscreen mode.

Depends on D9442

Differential Revision: https://phabricator.services.mozilla.com/D9443

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D9442

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D9597

Differential Revision: https://phabricator.services.mozilla.com/D9290

Make MarkDestroyed call MakeCurrent(force=true) to clear the current
context also.

Differential Revision: https://phabricator.services.mozilla.com/D9289

MozReview-Commit-ID: EUk2uc64Tok

Differential Revision: https://phabricator.services.mozilla.com/D9288

Passes deqp/functional/gles3/lifetime.html.

Differential Revision: https://phabricator.services.mozilla.com/D8956

Bug 1493742 - When accepting a layout viewport update from the main thread, constrain its position to enclose the visual viewport. r=kats

APZ wants the *size* of the layout viewport from the main thread, but it
knows the position better.

Differential Revision: https://phabricator.services.mozilla.com/D9448

--HG--
extra : moz-landing-system : lando

Due to https://github.com/adrienverge/yamllint/issues/141 we can't indent the
comments to the appropriate level.

Differential Revision: https://phabricator.services.mozilla.com/D9698

--HG--
extra : moz-landing-system : lando

Sharing tabs with file:// URIs is not possible, but users can still send them to
other apps via the helper app system in the URL bar/context menu. "Intent:Open"
and "Intent:OpenForResult" are both sent from Gecko by HelperApps.jsm.

The same reasoning as in bug 1450449 applies as to why for publicly accessible
files content:// URIs are more trouble than they're worth.

Differential Revision: https://phabricator.services.mozilla.com/D9420

--HG--
extra : moz-landing-system : lando

--HG--
extra : amend_source : 608437e414f153580a51c5b5b85b7478a8b11f60

Differential Revision: https://phabricator.services.mozilla.com/D9464

--HG--
extra : moz-landing-system : lando

--HG--
extra : amend_source : a8c2fc853b496dae7983ceaca51156f0e85e8f99