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
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
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
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D89871
This patch initializes some HAL components greedily so that we can get rid of
lazy initializers within the code. Observers are still lazily initialized
because they can be instanced within content processes but that doesn't always
happen and we don't want to pay the memory price for structures we don't use.
Shutdown is now happening at a fixed time for all HAL components save
WakeLocks. This ensures that we don't destroy an object while still iterating
over it, something that could happen before.
Finally a workaround for a compiler limitation has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D3100
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
This also replaces the custom logic in ObserverList with an nsTObserverArray
which has all the necessary logic for stable iteration over a potentially
changing list of items. Unused dependencies were also removed.
--HG--
extra : source : 303478f7f248470a1c747f42dad9cb85c3129f0a
This also replaces the custom logic in ObserverList with an nsTObserverArray
which has all the necessary logic for stable iteration over a potentially
changing list of items. Unused dependencies were also removed.
--HG--
extra : source : 1a83516d2ee5939052c5fb226b81563a0d114ff9
Time API is already removed, so hal backend is unnecessary now.
MozReview-Commit-ID: 8R2VRYIX9Vs
--HG--
extra : rebase_source : 4e927dcf0f0d2a3ae802332fff438985b0be14f1
By bug 130884, we removed alarm API, so we should remove alarm backend from HAL.
MozReview-Commit-ID: EBiMJSUfUHu
--HG--
extra : rebase_source : d8c7b3592377702e789ccb1402124f1ecf2cdc01
The new HAL interface allows for starting, stopping, and querying
the status of system services. How these operations are performed
depends on the underlying system.
The current implementation for Gonk already contains a workaround
from Bluetooth, where quickly restarted system services require a
cool-down time between retrys.