Bug 1808598, part 2 - Get rid of some unused nested declarations. r=ipc-reviewers,necko-reviewers,nika

None of the messages use these nested values.

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

Bug 1775062 - Fix various using statements to use properly qualified names. r=nika,necko-reviewers,valentin

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

natural is defined as (from https://w3c.github.io/screen-orientation/#dfn-natural)

> A computer monitor are commonly naturally landscape-primary, while a mobile
> phones are commonly naturally portrait-primary.

But GeckoView sets `SCREEN_ORIENTATION_UNSPECIFIED` that is unlock orientation.

Like Blink, we should set landscape-primary or portrait-primary (depends on
current monitor).

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

Now hal uses AR_STATE for screen orientation, so we should move it from
WinUtils.cpp to WinUtils.h for newer Windows 11 SDK.

Also, newer Windows SDK has to set WINVER to WIN8 to use auto rotation API.

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

Since Windows tablet mode has a orientation lock API, this patch
implements orientation lock backend for Windows tablet mode.

`GetAutoRotationState` API recognizes whether orientation API is supported on
the device. So this fix uses this API to check orientation API capability.

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

Bug 1800412 - Add a preference to control whether the EcoQoS is used for background content processes, r=gsvelto.

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

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

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

Bug 1771712 - Make it more likely for child processes to be killed under OOM conditions compared to the parent process on Linux r=jld

This patch implements hal::SetProcessPriority() on Linux and leverages
it to make it more likely that the parent process and foreground tab
survive an OOM situation, letting Linux' OOM killer reap preallocated
processes and background tabs first when reclaiming memory.

This is achieved by setting the `oom_score_adj` values of said processes
such that they will be killed in this order:

* Preallocated processes will be the first to go, they don't contain
  user data and are not visible, so they're a good candidate to free up
  memory
* Background tabs will be killed next, we don't generate crash reports
  for thoes nor do we inform the user, we just reload the tab, so in
  most cases one being killed will only be a small annoyance
* Background tabs playing video come next, but only if they're not also
  playing or recording audio
* Finally foreground tabs will be killed as a last resort, background
  tabs playing audio or with an active WebRTC session are also
  considered to be in the foreground as the user will immediately notice
  if they crash

Note that this patch only implements the low-level plumbing. The process
priority manager has not been enabled on Linux yet so that needs to
happen before this actually works.

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

Bug 1780788 - Use abstract strings as in-arguments for ipdl. r=nika,necko-reviewers,media-playback-reviewers,alwu,dragana

This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.

Non-virtual actors can still use `nsString` if they need to on the
receiving end.

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

Bug 1775154 - Extra cleanup of dom/, extensions/, hal/, netwerk/ and storage/ includes r=necko-reviewers,kershaw

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

Bug 1767346 - Use browsing context activeness rather than renderLayers to determine process priority. r=mccr8,mconley,geckoview-reviewers,agi

For desktop this should basically have no impact (maybe impacts tab
warming, but if we wanted we could set the priority hint from the tab
switcher the same way we set renderLayers), but Fenix always has
renderLayers as true, effectively, so we were never de-prioritizing the
background tab processes.

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

Bug 1767346 - Use browsing context activeness rather than renderLayers to determine process priority. r=mccr8,mconley,geckoview-reviewers,agi

For desktop this should basically have no impact (maybe impacts tab
warming, but if we wanted we could set the priority hint from the tab
switcher the same way we set renderLayers), but Fenix always has
renderLayers as true, effectively, so we were never de-prioritizing the
background tab processes.

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

This fixes a couple potential leaks (e.g., see the UPowerClient changes,
we weren't freeing all the devices properly).

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

From https://w3c.github.io/screen-orientation/#apply-an-orientation-lock

> 7.2. Apply an orientation lock
>
> The steps to apply an orientation lock to a Document using orientation are as
> follows:
>
>  1. If the user agent does not support locking the screen orientation, return
>     a promise rejected with a "NotSupportedError" DOMException and abort
>     these steps.

So if orientation controller delegate isn't set, we should throw
`NotSupportedError`.  But, actually, we throws `AbortError`, so this isn't
correct.

To return any DOM error from platform implementation of
`screen.orientation.lock`, I would like to change return value to
`GenericPromise`'s.

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

Make the ScreenOrientation part of the screen struct, as it should. Stop
using HAL to propagate just screen orientation updates, use the more
general screen manager.

Instead of HAL observers, add a simple observer service notification,
and clean a bunch of the code.

This will simplify bug 1754802 a bit, and is generally simpler.
Shouldn't change behavior. I've tested the events and some common
orientation locking use cases like Youtube, and they behave the same.

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

This adds proper IPC validation too.

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

The changes to ipdl actors were mechanical, and largely automated using
a script.

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

Bug 1752444 - Part 2: Rewrite direct_call.py protocols to use {Parent,Child}Impl attributes, r=ipc-reviewers,media-playback-reviewers,alwu,mccr8

This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.

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

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

Backed out changeset cd96e020a609 (bug 1747138) for causing bc failures in browser_telemetry_video_hardware_decoding_support. CLOSED TREE

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

Bug 1750142 - Support screen.orientation.lock('any') on GeckoView backend. r=geckoview-reviewers,calu

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

We should return rejected promise instead of `nullptr` to make simple.

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

Bug 1748981 - hal::LockScreenOrientation in content process never returns rejected promise even if platform's implementation returns rejected promise. r=calu

IPC's promise returns resolved promise when IPC connection is successful. So
even if platform implementations such as android returns rejected promise, it
 is converted to resolved promise by SandboxHal.cpp unfortunately.

So we should check return value when RecvLockScreenOrientation returns false.

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

Backed out changeset 5e151bd74f2a (bug 1748981)
Backed out changeset 4df658fcf42d (bug 1748981)

Bug 1748981 - hal::LockScreenOrientation in content process never returns rejected promise even if platform's implementation returns rejected promise. r=calu

IPC's promise returns resolved promise when IPC connection is successful. So
even if platform implementations such as android returns rejected promise, it
 is converted to resolved promise by SandboxHal.cpp unfortunately.

So we should check return value when RecvLockScreenOrientation returns false.

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

Bug 1748981 - hal::LockScreenOrientation in content process never returns rejected promise even if platform's implementation returns rejected promise. r=calu

IPC's promise returns resolved promise when IPC connection is successful. So
even if platform implementations such as android returns rejected promise, it
 is converted to resolved promise by SandboxHal.cpp unfortunately.

So we should check return value when RecvLockScreenOrientation returns false.

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

Bug 1747677 - Add utility method to convert to ScreenConfiguration. r=gsvelto,geckoview-reviewers,calu

Gecko uses the redundant code from nsIScreen to SCreenConfiguration. So we
should add a convert method for newer platform implementations.

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

Unlocking the screen orientation means locking the device to its default orientation. It is the same as calling `screen.orientation.lock('natural')`, where natural means the "device manufacturer's considered default orientation". That corresponds to the GeckoScreenOrientation constant `ScreenOrientation_Default`. In the Java public API, ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED corresponds to default, as specified by chromium (https://chromium.googlesource.com/chromium/src/+/66.0.3359.158/content/public/android/java/src/org/chromium/content/browser/ScreenOrientationProvider.java).

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

Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.

Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.

Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.

The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.

A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.

Reference:
Orientation constant values:
    C++
        1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
        2 ScreenOrientation_PortraitSecondary); - vertical with button at top
        4 ScreenOrientation_LandscapePrimary); - horizational w button right
        8 ScreenOrientation_LandscapeSecondary); - horization button left
        16 ScreenOrientation_Default);
    Java
        1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
        2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
        4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
        8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value

    Java public API
        0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
        1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT

    Android
        1 ORIENTATION_PORTRAIT
        2 ORIENTATION_LANDSCAPE

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

Backed out changeset 05897abf2c4e (bug 1697647) for causing failures at lock-sandboxed-iframe.html. CLOSED TREE

Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.

Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.

Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.

The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.

A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.

Reference:
Orientation constant values:
    C++
        1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
        2 ScreenOrientation_PortraitSecondary); - vertical with button at top
        4 ScreenOrientation_LandscapePrimary); - horizational w button right
        8 ScreenOrientation_LandscapeSecondary); - horization button left
        16 ScreenOrientation_Default);
    Java
        1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
        2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
        4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
        8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value

    Java public API
        0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
        1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT

    Android
        1 ORIENTATION_PORTRAIT
        2 ORIENTATION_LANDSCAPE

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

Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.

Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.

Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.

The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.

A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.

Reference:
Orientation constant values:
    C++
        1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
        2 ScreenOrientation_PortraitSecondary); - vertical with button at top
        4 ScreenOrientation_LandscapePrimary); - horizational w button right
        8 ScreenOrientation_LandscapeSecondary); - horization button left
        16 ScreenOrientation_Default);
    Java
        1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
        2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
        4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
        8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value

    Java public API
        0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
        1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT

    Android
        1 ORIENTATION_PORTRAIT
        2 ORIENTATION_LANDSCAPE

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

Bug 1725145 - Preparation for the hybrid build env. r=necko-reviewers,firefox-build-system-reviewers,valentin,glandium

Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.

This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.

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

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

As far as I can see, all this does is protect the user from
running some useless code if they manually enable the priority
manager using a pref on an OS that doesn't support it. The
upside of allowing this is that it makes it possible to debug
the priority manager on OSX and Linux with just a pref flip.

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