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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
Note that this removes `window.ondeviceproximity` and `window.onuserproximity` which unexpectedly have been exposed unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D109160
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
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
Makoto Kato
Andrew McCreight
Emilio Cobos Álvarez
Florian Queze
Gabriele Svelto
serge-sans-paille
Marian-Vasile Laza
Nika Layzell
smolnar
Cathy Lu
Butkovits Atila
criss
Andi-Bogdan Postelnicu
Kashav Madan
Kagami Sascha Rosylight
Agi Sferro
Simon Giesecke