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
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 patch makes it so we only ignore duplicated start events if there is a
request in progress, so that navigating to the same URI twice in a row will
results in the right events being fired.
Differential Revision: https://phabricator.services.mozilla.com/D95596
There is an unfortunate-but-necessary ordering issue that needs to be fixed in
the api.txt file which is causing a lot of one time updates. The ordering of
annotations was not stable (and now it is).
Differential Revision: https://phabricator.services.mozilla.com/D95382
As a result of part 1, we need to make this change, as this method needs to
be wrapped for the benefit of native code.
Not only does this patch fix the build error, but it also acts as an examplar
for how to explicitly annotate additional members of the `enum`.
Depends on D95203
Differential Revision: https://phabricator.services.mozilla.com/D95204
Our annotation processing for `enum`s kind of sucks.
The typical use case is that we want to generate wrappers for the values of the
`enum`.
On the one hand, we can annotate each individual enumerated value with
`@WrapForJNI` which is noisy and error-prone.
On the other hand, we can mark the entire `enum` as `@WrapForJNI`, which causes
everything in the enum to get JNI wrappers, including private members that we
typically don't care about. This pollutes the generated JNI wrappers with noise
and makes it harder for somebody inspecting the generated C++ header to find
relevant information.
This patch modifies the annotation processor so that `enum`s are treated as a
special case: when we mark an entire `enum` as `@WrapForJNI`, only the
enumerated values will be wrapped. Any additional fields or methods that we need
to wrap may then be annotated on a case-by-case basis.
This should give us both cleaner Java and cleaner generated C++.
Differential Revision: https://phabricator.services.mozilla.com/D95203
Simon Giesecke
pbz
Markus Stange
Razvan Maries
David Parks
Makoto Kato
Bogdan Tara
Johann Hofmann
Csoregi Natalia
Nika Layzell
Hiroyuki Ikezoe
Agi Sferro
Dylan Roeh
Butkovits Atila
Chris Martin
Botond Ballo
Aaron Klotz
Chris H-C
Neil Deakin
John Lin
Bharath S
Ricky Stewart
Cristina Coroiu