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
There is not a good way to know whether the server takes into account the client's priority suggestion or whether it is applying any kind of prioritization.
The only feedback there is from the server is the "priority" header. We will use this to isolate a subset of HTTP/3 connections that are more likely to apply priorities and measure their page load time and time to first paint. If we have enough data we will do an experiment to measure whether HTTP/3 priorities sent by the client improve performance.
Differential Revision: https://phabricator.services.mozilla.com/D132669
Remote rtcp-fb is something that the receive codec negotiates, and the pt of
the receive codec can be different than the pt in the remote SDP. So, we need
to first determine which remote pt corresponds to the receive codec, and then
look for something that matches it.
Depends on D132827
Differential Revision: https://phabricator.services.mozilla.com/D132828
This unifies most of the calls in nsUnicodeProperties.h. CharType and Script
will be handled in subsequent patches on this bug.
Differential Revision: https://phabricator.services.mozilla.com/D132273
With Fission, the process containing the initial page in the iframe
for the iframe navigation test might start shutting down after we
navigate away from it, because nothing else is loaded into it. If
this happens, the process will become FOREGROUND priority, causing
a test failure. See bug 1727340.
To work around this, I open an additional tab that is same-site with
the initial iframe, which should ensure that the process doesn't go
away too soon.
I also factored out a function to open a new tab.
Differential Revision: https://phabricator.services.mozilla.com/D132628
Also, add a comment about how you can run the priority manager tests on
non-Windows platforms, and rename some variables for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D132382
Recently hardware video decoding is enabled by default for WebRTC and there isn't any fallback if it fails.
Let's try HW decoding first and fallback to SW decoding if we fail as we do for media video playback.
Differential Revision: https://phabricator.services.mozilla.com/D132492
If the string pref is not set, then pref lookup fails. If the lookup
fails, we interpret it as an error (rather than a missing pref) and
bail early.
This means that we never set sJSHacksChecked and no telemetry will be
sent because we permit everything. (It also means we do a ton of pref
lookups all the time because every one of them fails.)
Differential Revision: https://phabricator.services.mozilla.com/D132727
This patchs adds new error messages which are extending existing ones,
providing extra information to the user.
A webconsole mochitest is added in the following patch of this stack.
Differential Revision: https://phabricator.services.mozilla.com/D131889
We want to record the number of registered and running ServiceWorkers, and
subset them by whether they support Fetch or not, in order to inform
decisions about isolating ServiceWorkers.
Also reenables some of the other ServiceWorker telemetry we used to collect
until FF 102
Differential Revision: https://phabricator.services.mozilla.com/D131563
Get frame color range from ffmpeg by av_frame_get_color_range() (we do the same for non VA-API path),
store to DMABufSurface and propagate to rendering thread.
Differential Revision: https://phabricator.services.mozilla.com/D132469
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
Now we use `mozilla::widget::ScreenManager` even if on content process, so no
one uses `PuppetScreen` and `PuppetScreenManager`.
And I would like to remove `Hal.h` reference from `PuppetWidget`, so I remove
unused method.
Differential Revision: https://phabricator.services.mozilla.com/D132564
There is a lot of the following `PSpeechSynthesisRequestParent` signature
crashes in Fenix since `mActor` seems to be null.
- `mozilla::dom::PSpeechSynthesisRequestParent::SendOnEnd`
- `mozilla::dom::PSpeechSynthesisRequestParent::SendOnBoundary`
- `mozilla::dom::PSpeechSynthesisRequestParent::SendOnStart`
So we should add a check whether child process is still alive.
Differential Revision: https://phabricator.services.mozilla.com/D132457
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Edgar Chen
Christoph Kerschbaumer
Andi-Bogdan Postelnicu
Butkovits Atila
Cathy Lu
criss
Dragana Damjanovic
Byron Campen [:bwc]
Dan Minor
Andrew McCreight
Barret Rennie
Joel Maher
Manuel Bucher
stransky
Masayuki Nakano
Tom Ritter
Randell Jesup
nchevobbe
Emilio Cobos Álvarez
Karl Tomlinson
Alexandru Michis
Csoregi Natalia
Jonatan Klemets
Dana Keeler
Makoto Kato
Gabriele Svelto
Andreas Pehrson
Gijs Kruitbosch
Sandor Molnar
Chris Peterson
Narcis Beleuzu
Marian-Vasile Laza