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

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

Bug 1604106 - Don't assert on error conditions when changing the priority of a process on Windows r=bobowen

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

Note that this removes `window.ondeviceproximity` and `window.onuserproximity` which unexpectedly have been exposed unconditionally.

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

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

Bug 16342819 - Use nsTHashMap instead of nsDataHashtable. r=xpcom-reviewers,necko-reviewers,jgilbert,nika,valentin

Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.

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

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

Bug 1691913 - Mark nsBaseHashtable (and its subclasses') member functions nodiscard where appropriate. r=xpcom-reviewers,necko-reviewers,dragana,nika

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

Bug 1691913 - Rename nsBaseHashtable::Put to InsertOrUpdate. r=xpcom-reviewers,necko-reviewers,jgilbert,dragana,nika

This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.

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

Bug 1691894 - Replace several suboptimal uses of Put after Get by GetOrInsertWith or WithEntryHandle. r=xpcom-reviewers,necko-reviewers,kmag,valentin,geckoview-reviewers,agi

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

Backed out 5 changesets (bug 1691894) for causing hazard failures in nsXULPrototypeCache. CLOSED TREE

Backed out changeset 22dc870ee609 (bug 1691894)
Backed out changeset 58c31e9d6ae3 (bug 1691894)
Backed out changeset 7483e84149d8 (bug 1691894)
Backed out changeset f977d6cfa973 (bug 1691894)
Backed out changeset db4503476f34 (bug 1691894)

Bug 1691894 - Replace several suboptimal uses of Put after Get by GetOrInsertWith or WithEntryHandle. r=xpcom-reviewers,necko-reviewers,kmag,valentin,geckoview-reviewers,agi

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