`devicePrompt.properties` ... Presentation API UI frontend for Fennec.
`phishing.dtd` ... Safe browsing API UI on Fennec.
`pippki.properties` ... NSS Dialog UI such as importing certificate of Fennec.
`sync.properties` ... Firefox sync UI on Fennec.
`webcompatReporter.properties` - Web compat addon on Fennec
`passwordmgr.properties` still be referenced from `LoginManagerPrompter.jsm`.
So, I'm not sure we should keep this.
Differential Revision: https://phabricator.services.mozilla.com/D99798
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
Makoto Kato
Emilio Cobos Álvarez
Dorel Luca
owlishDeveloper
Eugen Sawin
Razvan Maries
Bogdan Tara
R. Martinho Fernandes
Geoff Brown
Agi Sferro
Chris Martin
Cristina Coroiu
Simon Giesecke
pbz
Markus Stange
David Parks
Johann Hofmann
Csoregi Natalia
Nika Layzell
Hiroyuki Ikezoe
Dylan Roeh
Butkovits Atila
Botond Ballo
Aaron Klotz