Add the permission to the geckoview manifest, as previously attempted. Also disable failing tests
to enable a green test run. Add permission to adb.py grants list for good measure.
Differential Revision: https://phabricator.services.mozilla.com/D98809
Currently, the gamepad code uses a uint32_t as a handle and does some trickery
with it by trying to create a unique ID and adding an offset to it for VR code.
This can (and has) led to errors where the developer forgets to perform the
arithmetic and sends the wrong number to the wrong manager.
This change created a strongly-typed handle that remembers which service it
belongs to. This should eliminate such accidents.
Differential Revision: https://phabricator.services.mozilla.com/D96273
Originally, this issue was bug 1283739. But I guess that this might be
regression by bug 1464096.
Actually, reentrant code seems to be broken now, so I make it simple.
Differential Revision: https://phabricator.services.mozilla.com/D97266
This uses the new deleteUserInteractionForClearingHistory API in GeckoView to avoid
clearing all storage access API permissions and thus causing purging to clear all cookies
and site data when clearing only history.
Differential Revision: https://phabricator.services.mozilla.com/D96642
This uses the new deleteUserInteractionForClearingHistory API in GeckoView to avoid
clearing all storage access API permissions and thus causing purging to clear all cookies
and site data when clearing only history.
Differential Revision: https://phabricator.services.mozilla.com/D96642
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
This allows adding another vsync listener that gets called before the regular VsyncSource.
And it allows adding the listener on the Java UI thread.
The existing infrastructure is pretty adamant about being used on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D96797
The extension code _tries_ to flush messages when the relevant delegate is attached.
The logic, however, is pretty flawed: we currently only flush runtime-messages
(i.e. not coming from a WebExtension Page) and we flush all messages when the
first delegate is attached, even though there could be messages for different
nativeApp values which don't have a delegate attached yet.
We also erroneusly return a rejected promise to javascript when a message is queued up.
This patch addresses the above by:
- Never rejecting a pending connection request, the connection request will be
resolved when the delegate for the right nativeApp is attached.
- Making the pending messages queue per-nativeApp and per-session.
- Flushing pending messages when a session delegate is attached.
Differential Revision: https://phabricator.services.mozilla.com/D96645
The extension code _tries_ to flush messages when the relevant delegate is attached.
The logic, however, is pretty flawed: we currently only flush runtime-messages
(i.e. not coming from a WebExtension Page) and we flush all messages when the
first delegate is attached, even though there could be messages for different
nativeApp values which don't have a delegate attached yet.
We also erroneusly return a rejected promise to javascript when a message is queued up.
This patch addresses the above by:
- Never rejecting a pending connection request, the connection request will be
resolved when the delegate for the right nativeApp is attached.
- Making the pending messages queue per-nativeApp and per-session.
- Flushing pending messages when a session delegate is attached.
Differential Revision: https://phabricator.services.mozilla.com/D96645
Currently, the AndroidGamepadManager uses a single function to both add and
remove gamepad service entries (Even though their functionality is different),
and it also uses a JNI callback to set the ID rather than simply returning it
This fixes both of those things.
Depends on D96270
Differential Revision: https://phabricator.services.mozilla.com/D96272
This patch adds some code to our annotation processor that produces comments in
our generated JNI headers to help the developer understand which types are
involved. There are two new types of comments:
* For generated methods from native to Java, we produce a simplified Java method
signature (sans package names) to help the caller disambiguate parameter
types. This is helpful since the machine-readable method signature tend to
use `mozilla::jni::Object::Param` instead of actual types (for the purposes of
avoiding dependency hell, presumably).
* For Java to native methods, we produce a sample signature that is usable for
the implementation of the native method.
While we did discuss some ideas about other locations where we could output this
data, I'd like to start with the generated header files for now. We can make
adjustments to the output location in future bugs.
I will be attaching an example of a generated header that contains these new
comments to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D96236
This makes the vsync times more consistent.
On a Pixel 2 running Android 11, the callback was called between 1ms and 6ms
after the vsync timestamp in my tests. Having the vsync timestamp slightly in
the past is what the rest of our vsync infrastructure expects.
Differential Revision: https://phabricator.services.mozilla.com/D96279
I want to start with 3 so that we initially get a good look at how things run
with multiple processes, but when we easily hit the limit. We'll increase to
our final process count in a future bug.
Differential Revision: https://phabricator.services.mozilla.com/D94884
Recording events involved asking whether they should go in the event ping or
not, and also whether we hit the limit for how many are allowed in a ping.
These values are stored in prefs which aren't terribly accessible off the main
thread, even if the event recording is.
Both of these prefs have been set in stone in their default values for over two
years now, so we can safely remove them and their scaffolding. Huzzah!
Differential Revision: https://phabricator.services.mozilla.com/D96102
On Android, software H.264 video encoder accepts some sizes when configuring
but will crash later after frames are sent to the encoder. Use method provided
in API 21+ to validate the input size and avoid using software encoder on
earlier versions to prevent crashes.
Differential Revision: https://phabricator.services.mozilla.com/D94461
The other fling acceleration restrictions make it so that there is no need for
this additional restriction anymore.
Removing this restriction allows a fling to be accelerated even if the previous
fling has been "spinning" for a while (a second or more), provided that the page
is still moving fast enough.
This matches Chrome's behavior.
Differential Revision: https://phabricator.services.mozilla.com/D95472
- The test cases cover with/without event handler, and with preventDefault in
the event handler
- The non-scrollable contents but covered by the dynamic toolbar cases don't
pass without the event handler now (the cases with the event handler have been
fixed by the previous change)
- There is a test case which don't pass at all right now, that is a case
(iframe_98vh_scrollable.html) that after scrolled at the bottom edge of an
iframe
Differential Revision: https://phabricator.services.mozilla.com/D93916
This change has a couple of tests but they are for scrollable/non-scrollable
contents, they are not for non-scrollable contents but covered by the dynamic
toolbar cases, e.g. 100vh body element. Those cases will be introduced in the
subsequent change.
Differential Revision: https://phabricator.services.mozilla.com/D93915
touchEventForResult is the only one test using touch.html and it doesn't use
`setDynamicToolbarMaxHeight`, which means the test is supposed to work with
static toolbar, so with this change it gets clearer what the test does.
(and we are going to add a bunch of tests with dynamic toolbar)
Differential Revision: https://phabricator.services.mozilla.com/D93913