The harmless looking regex
```
uri.matches("(http|blob).*")
```
has a flaw: it will not accept URLs that contain a new line character. In that
case GeckoWebExecutor errors out with "Unsupported URI scheme." when in reality
that's not the problem at all.
Since it has caused a bunch of headaches to the frontend already, let's just
replace that regex with a plain `startsWith` which should work in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D102943
- Made asyncPromptAuth fully async.
- Removed auth prompt queuing from LoginManagerAuthPrompter asyncPromptAuth implementation.
- If there are multiple auth prompts with the same target in a tab, consolidate them.
- Removed unused method asyncPromptAuthBC.
- Fixed an issue with PromptTestUtils#waitForPrompt where it didn't always return
the correct prompt.
- Added test for multi tab auth prompts.
Differential Revision: https://phabricator.services.mozilla.com/D102306
This patch makes the aName in the GeckoViewNavigation.openURIInFrame() to
be set properly to the new opened window when calling window.open() with
'noopener'.
Differential Revision: https://phabricator.services.mozilla.com/D102240
Implement manifest v3 CSP that is compatible with the current chrome implementation.
Support for content_security_policy.isolated_world (a.k.a. content_security_policy.content_scripts)
has been removed for consistency with
345390adf6%5E%21/
Differential Revision: https://phabricator.services.mozilla.com/D100573
As is the case with GTK, Android provides an OS override to display times in
AM/PM or 24 hour format. This moves the code for rewriting skeletons from the
GTK specific code to OSPreferences, and calls it from the Android OSPreferences
implementation.
This was tested manually by visiting the file:/// uri. I don't believe this is
feasible to test from automation, as it would require changing Android OS settings
from within our test code.
Differential Revision: https://phabricator.services.mozilla.com/D101641
One thing I've noticed before going on break last year is that a lot of the
times we don't close out promises when an error occurs. Our code normally does
something like:
```
delegatePromise.then(response -> {
// manipulate response
callback.resolve(manipulatedResponse);
})
```
where `delegatePromise` is the `GeckoResult` from a delegate. The problem here
is that if the `delegatePromise` is rejected, the above never rejects the
callback.
A month ago we introduced `callback.resolveTo(result)` which obviates this
problem a little bit (it will rejects the callback if the result is rejected)
but it's still a little hard to use because you need to then the result to the
right value.
`result.map` sort of closes this gap a little bit and now you can write
something like this:
```
callback.resolveTo(delegatePromise.map(value -> {
// manipulate value to match the response
return manipulatedValue;
});
```
Which is the recommended way to resolve callbacks in GV
Another problem with callback.reject is that we pretty much only support strings but it's not made really clear (some existing code in GV returns an exception there, which doesn't work). resolveTo will take care of that by using the message of the exception passed in
Differential Revision: https://phabricator.services.mozilla.com/D101093
There is only one place where it's used:
config/check_vanilla_allocations.py, which is only executed from
js/src/build/Makefile.in on the condition that the build is targeting
Linux and not LTO. But the LTO test is actually outdated, because we
don't build with `-flto`, but `-flto=thin`, so the exclusion doesn't
work anymore.
There is however no AC_CHECK_PROG, and we currently rely on NM to be
given, or fall back to "nm", which works in most cases, except LTO with
clang. It works on CI because in LTO builds we explicitly set NM to
llvm-nm (which can output symbols from LLVM bitcode objects), but we
could also do that automatically.
So we add a full detection of nm/llvm-nm to python configure, and limit
it to Linux, since we only ever use it there.
Differential Revision: https://phabricator.services.mozilla.com/D101681
As is the case with GTK, Android provides an OS override to display times in
AM/PM or 24 hour format. This moves the code for rewriting skeletons from the
GTK specific code to OSPreferences, and calls it from the Android OSPreferences
implementation.
This was tested manually by visiting the file:/// uri. I don't believe this is
feasible to test from automation, as it would require changing Android OS settings
from within our test code.
Differential Revision: https://phabricator.services.mozilla.com/D101641
This patch converts `GeckoChildProcessServices.java` into a jinja template.
We also add an overlay generated from a jinja template for `AndroidManifest.xml`
that provides the definitions for content process services.
Note that even though Gradle supports simple substitution of variables in
manifests, I opted not to use that functionality. Since we need the more
powerful template functionality that jinja provides, I felt that having multiple
ways to substitute information into the manifest would be confusing, so we're
using jinja exclusively.
Differential Revision: https://phabricator.services.mozilla.com/D82578
* We add a config option for setting the number of content services;
* We add a config option to indicate whether content services should be isolated.
This one is just a `project_flag` since it doesn't really need the ability to
be overridden; it's something whose default we would want to flip when the
time comes;
* We set a dependency so that mobile/android/base/pre-export is executed;
* We add the `gen_from_jinja.py` script which is mostly just a dumb shim that
takes the input template and the config arguments, instantiates jinja,
generates the final output, and dumps it to the output fd;
* We add the requisite `moz.build` statements to generate the manifest overlay
and the service definitions;
* We update `build.gradle` so that Gradle knows to look for the generated files
when building the apk.
Differential Revision: https://phabricator.services.mozilla.com/D82577
This patch converts `GeckoChildProcessServices.java` into a jinja template.
We also add an overlay generated from a jinja template for `AndroidManifest.xml`
that provides the definitions for content process services.
Note that even though Gradle supports simple substitution of variables in
manifests, I opted not to use that functionality. Since we need the more
powerful template functionality that jinja provides, I felt that having multiple
ways to substitute information into the manifest would be confusing, so we're
using jinja exclusively.
Differential Revision: https://phabricator.services.mozilla.com/D82578
* We add a config option for setting the number of content services;
* We add a config option to indicate whether content services should be isolated.
This one is just a `project_flag` since it doesn't really need the ability to
be overridden; it's something whose default we would want to flip when the
time comes;
* We set a dependency so that mobile/android/base/pre-export is executed;
* We add the `gen_from_jinja.py` script which is mostly just a dumb shim that
takes the input template and the config arguments, instantiates jinja,
generates the final output, and dumps it to the output fd;
* We add the requisite `moz.build` statements to generate the manifest overlay
and the service definitions;
* We update `build.gradle` so that Gradle knows to look for the generated files
when building the apk.
Differential Revision: https://phabricator.services.mozilla.com/D82577
Gecko already broadcasts `memory-pressure` events from the parent process down
to its content processes, but that excludes any case where Android is calling
`Service.onTrimMemory` directly on the content processes.
This patch handles `onTrimMemory` and translates its requests into
`memory-pressure` events that various Gecko components (including the GC)
listen for. We only handle the severity levels for background processes for now,
as memory cleanup for background processes is currently the most pressing issue
(and I'm not even sure what we could do for foreground memory cleanup without
janking anything).
The argument to `memory-pressure` should depend on the severity of the request
as well as the frequency of pressure events. In particular:
* The most severe request, `TRIM_MEMORY_COMPLETE`, is a last-ditch effort to
reduce memory. This should trigger a full GC, so we use `low-memory` here.
* "New" requests, where "new" is defined as an event that was triggered in
excess of 10 seconds since the previous "new" event, also gets a full GC, so we
use `low-memory` here as well.
* Additional requests that do not fall under either of the above criteria
receive the `low-memory-ongoing` event, which omits a full GC. The idea here
is that, when low memory notifications occur in rapid succession, repeatedly
doing full GCs over and over is just going to hang the Gecko thread and not
result in any notable improvement.
Differential Revision: https://phabricator.services.mozilla.com/D101406
This patch adds `queryString`, `queryBoolean`, `queryVoid` and `queryBundle` to
`EventDispatcher` in place of `dispatch(type, message, callback)`.
These `query*` methods returns a `GeckoResult` which can be manipulated using
`GeckoResult.map`.
Differential Revision: https://phabricator.services.mozilla.com/D96951