The problem here is that sometimes the test clicks on the two links too quickly
and only the second click goes through the onBeforeUnload path and the first
one is ignored.
Differential Revision: https://phabricator.services.mozilla.com/D82442
If client script wants to commit composition string per input, it sometimes
use the following script.
```
let input = document.getElementById('input');
input.addEventListener('input', () => {
input.blur();
input.focus();
});
```
Since `blur` will commit composition string, this script can commit text. But
since Gecko has an optimization for this situation, focus won't be lost
completely.
Although GeckoView synchronizes Java text and selection with Gecko text when
getting focus, this sample may be failed due to timing issue. `blur` tries to
commit string, but result is never returned since focus is lost as temporary
(although text is finally committed in Gecko.). Then, GeckoView are waiting
for result that is never returned forever, So this synchronization is failed.
When getting focus again, we should synchronize it at force.
Differential Revision: https://phabricator.services.mozilla.com/D80147
I intend to uplift this patch to v79, so the changelog references 79 and the
version for removal is indicated as v82.
Differential Revision: https://phabricator.services.mozilla.com/D82033
Note: These comments reference GeckoView 82 instead of GeckoView 83 because I
plan to uplift this to GeckoView 79. Ditto for the changelog entry.
Tests that use the parcelable functionality are flagged to ignore deprecation
warnings.
Differential Revision: https://phabricator.services.mozilla.com/D81768
Note: These comments reference GeckoView 82 instead of GeckoView 83 because I
plan to uplift this to GeckoView 79. Ditto for the changelog entry.
Tests that use the parcelable functionality are flagged to ignore deprecation
warnings.
Differential Revision: https://phabricator.services.mozilla.com/D81768
The profiler can be "paused", which stops sampling, and since bug 1578329 stops markers as well.
Some test suites use pausing between tests (to better differentiate the tests, to keep the profiler ready to run, and to lower the amount of recorded data). But this causes problems with some tracing markers, as their matching ends have not been recorded (e.g., an end marker is missing), which show up as very loooong markers.
To solve this, we need to be able to pause sampling only, but keep recording markers.
But we still need to be able to pause the whole profiler, in particular before capturing, to avoid recording anything around that time.
This big patch is mostly mechanical changes: Wherever there are "Pause" and "Unpause/Resume" profiler functions, we add matching "PauseSampling" and "UnpauseSampling/ResumeSampling" functions that only impact the periodic sampling loop; And existing "Pause/Unpause/Resume" imply pausing sampling as well.
Exceptions and extra work:
- nsIProfiler (the JS API) already had `Pause/ResumeSampling()`, which misleadingly paused everything! Now they do the right thing, and we have `Pause/Resume()` as well.
- All tests using `Pause/ResumeSampling()` now use `Pause/Resume()`, except for Talos tests that only pause sampling between tests; Added some extra `Pause()` calls to pause everything before capturing profiles.
- GeckoJavaSampler doesn't handle pausing/resuming everything, this should be done in a follow-up bug.
- Sampling-only pauses are not streamed into JSON. If needed, we should follow-up, with potential work on the front-end to deal with these.
Differential Revision: https://phabricator.services.mozilla.com/D81492
Because jar_maker is not in the libs tier, we also rename the libs-%
targets for l10n repacks to l10n-%, which make it clearer what they are
for.
And because multilocale.txt is both a GeneratedFile and a file that is
generated (and installed) via manual build rules, keeping it in the misc
target actually breaks building in toolkit/locales during l10n repacks,
so move it to libs for now.
Differential Revision: https://phabricator.services.mozilla.com/D81766
The only fallout from part 1 is a single test where we run `evaluateJS` on a session, serialize it to a `Parcel`,
deserialize it to new, distinct `GeckoSession` object, and then perform additional `evaluateJS` on the latter.
Since the deserialization of the `Parcel` transferred the session's contents from the original session to the new
session, we also need to transfer the `WebExtension.Port` used by `evaluateJS` to the new session.
Note that this fix is kind of hacky, but because we are going to deprecate the parcelability of `GeckoSession`, I
do not believe that it is worth the effort to implement a "perfect" fix; that would likely involve adding new APIs
to support another API that we are going to deprecate anyway.
Depends on D81746
Differential Revision: https://phabricator.services.mozilla.com/D81748
Because `GeckoSession`'s overrides of `hashCode` and `equals` look solely at session ID, this may cause
strange behaviors if a `GeckoSession` is reloaded with session state from a previous instance, and the
previous instance still exists. For example, suppose the previous instance is closed and the new instance is
open. As far as the Android runtime is concerned, both objects are equivalent. Trying to insert both objects
into the same container will not work as expected.
In this patch, we revert those overrides. To ensure that we still have a short-circuit path in
`GeckoView.restoreSession`, we add and utilize a new, `package`-scoped, `equalsId` method.
Differential Revision: https://phabricator.services.mozilla.com/D81746
The only fallout from part 1 is a single test where we run `evaluateJS` on a session, serialize it to a `Parcel`,
deserialize it to new, distinct `GeckoSession` object, and then perform additional `evaluateJS` on the latter.
Since the deserialization of the `Parcel` transferred the session's contents from the original session to the new
session, we also need to transfer the `WebExtension.Port` used by `evaluateJS` to the new session.
Note that this fix is kind of hacky, but because we are going to deprecate the parcelability of `GeckoSession`, I
do not believe that it is worth the effort to implement a "perfect" fix; that would likely involve adding new APIs
to support another API that we are going to deprecate anyway.
Depends on D81746
Differential Revision: https://phabricator.services.mozilla.com/D81748
Because `GeckoSession`'s overrides of `hashCode` and `equals` look solely at session ID, this may cause
strange behaviors if a `GeckoSession` is reloaded with session state from a previous instance, and the
previous instance still exists. For example, suppose the previous instance is closed and the new instance is
open. As far as the Android runtime is concerned, both objects are equivalent. Trying to insert both objects
into the same container will not work as expected.
In this patch, we revert those overrides. To ensure that we still have a short-circuit path in
`GeckoView.restoreSession`, we add and utilize a new, `package`-scoped, `equalsId` method.
Differential Revision: https://phabricator.services.mozilla.com/D81746
We don't use it and causes confusion when `mach install` fails because the
signature of `geckoview_example.test` doesn't match.
Differential Revision: https://phabricator.services.mozilla.com/D81606
In bug 1645264, extension resources could not be loaded when extensions
were loaded through the deprecated `registerWebExtension` method,
because the base URL of such extensions were not correctly resolved.
This does work as expected with the new `installBuiltin` method because
that relies on the AddonManager, which internally does resolve the URL
as expected.
This patch does not fix the bug because the deprecated method is going
to be removed, but introduces a regression test to make sure that this
functionality continues to work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D80300
No behavior change actually (as instant is the default behavior), but I
just noticed it while debugging these.
Depends on D80723
Differential Revision: https://phabricator.services.mozilla.com/D80724
`charsetMenu.properies` was for "Text Encoding" menu in Fennec (bug 611580).
EN was off as default, but some language such JA turned on this menu.
Since Fennec is gone, it is unnecessary now, so let's remove this resource.
Differential Revision: https://phabricator.services.mozilla.com/D79634
When using `enterkeyhint` attribute, key event must be be fired as enter key.
So by previous changeset, I change action type to `maybenext` if inferring
action type without `enterkeyhint`.
Also, `enterkeyhint` can have additional values (enter and previous), so Android
back end should support it.
Differential Revision: https://phabricator.services.mozilla.com/D79646
`charsetMenu.properies` was for "Text Encoding" menu in Fennec (bug 611580).
EN was off as default, but some language such JA turned on this menu.
Since Fennec is gone, it is unnecessary now, so let's remove this resource.
Differential Revision: https://phabricator.services.mozilla.com/D79634
Additionally, recommends the installation of AdoptOpenJDK instead of the Oracle JDK.
This required a different "JAVA_HOME" detection mechanism, which is implemented in this revision.
Differential Revision: https://phabricator.services.mozilla.com/D79547
This removes the support for the 'geckoview' telemetry in
the core and in the JSM files. It also cleans up testing
and the configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79521
This removes the support for the 'geckoview' telemetry in
the core and in the JSM files. It also cleans up testing
and the configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79521
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This is a weird conversion because the existing VarCache mirror prefs are in a
two static structs, one for touch prefs and one for the equivalent mouse prefs,
and we dynamically select the appropriate struct in `GetPrefsFor()`.
(But note that `ui.mouse.radius.reposition` and
`ui.mouse.radius.inputSource.touchOnly` do not have corresponding `touch`
prefs! For touch events they are always considered to be false.)
The commit make the following changes.
- It makes the prefs into static prefs.
- It moves the code in `GetPrefsFor()` into a constructor for
`EventRadiusPrefs`, and copies the pref values into a temporary object of
that type. Those copied values are then used by the subsequent code.
- It removes the two static `EventRadiusPrefs` structs.
- It renames some fields in `EventRadiusPrefs` to make them more closely match
the pref names.
Differential Revision: https://phabricator.services.mozilla.com/D79405
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
Updated API docs to reflect removed method
Removed incorrect line to fix some bugs
Updated changelog
Added listener registration back into WebExtension Listener constructor
Differential Revision: https://phabricator.services.mozilla.com/D78977
`numUnbindFailures` can never be non-zero (since any unbind failures throw), so
we should just eliminate this variable.
Differential Revision: https://phabricator.services.mozilla.com/D78362
Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
As it turns out, javadoc output is not stable across platforms / OSs / versions
(not a big suprise).
E.g. in try this is an example line:
```
/builds/worker/checkouts/gecko/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoRuntimeSettings.java:1124: warning - Tag @link: reference not found: Autocomplete.LoginStorageDelegate.onLoginFetch onLoginFetch
```
on my mac, this is the same error:
```
/Users/asferro/workspace/mozilla-central/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoRuntimeSettings.java:1118: error: reference not found
* {@link Autocomplete.LoginStorageDelegate.onLoginFetch onLoginFetch}.
```
Notice the `-` character after `warning` in the first example and the `:`
character after the second example.
To be able to parse both this patch simiplifies the regex and also adds a
failsafe that will mark anything that contains the string "error" and "warning"
as such.
Differential Revision: https://phabricator.services.mozilla.com/D77545
`|mach lint -f treeherder|` expects lint to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
`|mach lint -f treeherder|` expects lints to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
The sender doesn't await a result, and the recipient does not send a
result. To get rid of logspam when the finalizer is invoked, simply
replace `sendRequestForResult` with `sendRequest`.
Differential Revision: https://phabricator.services.mozilla.com/D77235
This crash hits when a `RemoteException` is thrown during `onServiceConnected`.
We `unbind`, which destroys all our bookkeeping data. During this destruction,
we also attempt to retrieve the pid, which fails because we lost our binding
before we had a chance to retrieve it.
This patch adds a new exception to be thrown in this case, which we explicitly
catch in `removeContentConnection`.
Differential Revision: https://phabricator.services.mozilla.com/D77135
In Bug 1622749 a user preference for where to open new documents (from a
service worker notification) was temporarily overriden in order to quickly fix
a crash that was happening in mozilla::dom::ClientOpenWindow. The crash was
ocurring when the pref "browser.link.open_newwindow" was set to 2, meaning new
documents are opened in a new window, instead of a new tab. The reason the
browser crashed is because the path for opening a new document is different
depending on the current user setting, and in NEWWINDOW case we did not get a
browsing context returned when calling mozilla::dom::OpenWindow which resulted
in a failed assertion.
The solution is to pass in a callback to mozilla::dom::OpenWindow as part of
nsOpenWindowInfo object, and invoke that callback with a corresponding
BrowsingContext in nsFrameLoader when that browsing context is ready.
After we call mozilla::dom::OpenWindow, we wait on a promise, that will be
resolved when the callback is invoked, before executing the rest of the code
that depends on the browsing context for a newly opened document being
available.
Differential Revision: https://phabricator.services.mozilla.com/D72745
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
`GeckoProcessManager.buildLogMsg` requires a successful bind to construct its
message, but its only remaining callsite is only invoked when a bind fails,
so it blows up.
This patch eliminates `buildLogMsg` and just changes the callsite to use
a string literal.
Differential Revision: https://phabricator.services.mozilla.com/D76086
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
* We modify connection management such that we now use more specific connection
types for {content, non-content, socket process} connections.
* We attach a native counterpart to the `GeckoProcessManager.ConnectionManager`
instance that listens for app foreground, app background, and when the
socket process is enabled, network state events.
* On app background, all non-content processes are assigned BACKGROUND priority.
Even though backgrounding the app will cause Android to drop all child
processes' priority regardless of our priority settings, we still do this as
to indicate to Android that these processes are relatively less important
than our parent process.
* When the socket process is enabled, we drop its priority when we detect that
we have no network connectivity. Note that the network management code does
the Right Thing if network connectivity changes while our app was in the
background: we receive the network state change event once we return to
foreground, therefore we do not need to do any special handling ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D74478
I'm wondering whether Gecko's response to noticing that the child process was
killed is causing some notifications on the launcher thread to arrive out of
order from others. Removing the kill since we can just let Android handle
process termination.
Differential Revision: https://phabricator.services.mozilla.com/D75416
Since this is so common, let's reserve the `AssertionError` for debug builds.
In non-debug builds we will throw a `ServiceAllocator.BindException` which
will be caught and used for completing the bind promise.
GeckoProcessManager will retry unbinding and restarting the process, which
hopefully will mitigate the problem.
We also make some improvements to exception handling hygeine.
Differential Revision: https://phabricator.services.mozilla.com/D75415
Currently `unbind()` is more or less synchronous, but since those semantics may
change in the future, for the sake of cleanliness we should ensure that our
reaction is linked to `unbindResult`.
Differential Revision: https://phabricator.services.mozilla.com/D75414
In bug 1470348 we started to detach all SurfaceTextures from the
current GL context in CompositorOGL::Pause(). This was required for
VR, so that when the VR presentation was entered the SurfaceTextures
could be attached to the VR context instead.
When RenderCompositorEGL was implemented for webrender, we copied the
call to detach from CompositorOGL. However, due to extra complexity in
webrender's threading model, this is causing assertion failures.
VR no longer relies upon the SurfaceTextures being detached when the
compositor is paused, as it now uses its own SurfaceTexture
set. Therefore we can remove the detach call from both
CompositorOGL::Pause and RenderCompositorEGL::Pause.
Differential Revision: https://phabricator.services.mozilla.com/D74832
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/GeneratedJNI
```
which are then exported to `mozilla/java`
Differential Revision: https://phabricator.services.mozilla.com/D74720
This establishes a "high-water" mark that will make new files not be
"unified", and will allow to burn down the list of files require
unification.
Depends on D58573
Differential Revision: https://phabricator.services.mozilla.com/D58574
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572