When tapping accessiblecaret and moving/releasing it, the follow error occurs.
```
GeckoViewContent[C]: handleEvent: mozcaretstatechanged
Web Content: [JavaScript Error: "TypeError: can't access property "sendRequest", this.eventDispatcher is undefined" {file: "resource:///actors/GeckoViewContentChild.jsm" line: 291}]
Web Content: handleEvent@resource:///actors/GeckoViewContentChild.jsm:291:11
```
I think that we miss super.actorCreated() call in actorCreate(). This might be
regression by bug 1661480.
Differential Revision: https://phabricator.services.mozilla.com/D124639
Hiro found this race condition.
The problem is in this code:
```
338: this.eventDispatcher
339: .sendRequestForResult(message)
340: .then(sessionId => {
341: return this.waitAndSetupWindow(sessionId, aOpenWindowInfo, aName);
342: })
```
At line 339 we ask the Java front-end to create a session and return back the
id of the session just created.
We then, at line 341, wait until the `geckoview-window-created` event fires
which signals that the session has been opened. We then _synchronously_ set
some attributes on the window object that allows us to connect the Java session
to the JavaScript window object.
Synchronicity is important as right after the `geckoview-window-created` event
fires all actors expect the embedderElement to be set on the window.
This, however, races with the code that creates the session:
```
540: } else if ("GeckoView:OnNewSession".equals(event)) {
541: final String uri = message.getString("uri");
542: final GeckoResult<GeckoSession> result = delegate.onNewSession(GeckoSession.this, uri);
...
547:
548: callback.resolveTo(result.map(session -> {
...
562: session.open(GeckoSession.this.mWindow.runtime);
563: return session.getId();
564: }));
```
As you can see, at line 562 we open the session, which asynchronously builds
the Gecko window and eventually fires the `geckoview-window-create` event. In
most cases, the message with the sessionId, sent at line 563, reaches the
JavaScript layer before the window has been opened, but sometimes it doesn't.
When the window opens before the JavaScript layer receives the sessionId back,
the promise at line 341 will never complete, causing intermittent failures in
our testing harness (and causing missing windows in consumer devices).
To fix this problem we modify the timing of creating the GeckoSession id.
The GeckoSession id only makes sense when the session is associated to a
GeckoRuntime instance, as the id is only used by Gecko. We can thus generate
the id whenever the Session is opened.
For sessions that are opened by the embedder directly, we can generate the id
randomly like usual. However, when the session is opened as a result of a
onNewSession (or onNewTab) call, we will set the id of the session using the id
given by the JavaScript layer.
This will enable the JavaScript layer to wait for the `geckoview-window-create`
before the Java layer has opportunity to respond, fixing the race condition.
Co-Authored-By: Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D124502
Actually `inputConnection_sendKeyEvent` test is rarely failed such as bug
1676245. Because we have no way to wait for correct selection data.
`TextInputDelegate.updateSelection` isn't called when view isn't attached to
window like geckoview-junit case.
So I would like to comment out this check now.
Depends on D124435
Differential Revision: https://phabricator.services.mozilla.com/D124436
The code in this patch is not needed anymore because now we can handle multiple
in-app runtimes after Bug 1696460.
This reverts commit d49a34c51bc537caffcd559cda07be994105cebb.
Differential Revision: https://phabricator.services.mozilla.com/D123980
This commit allows Android to use the login storage for HTTP auth by migrating
some common toolkit code to promptUsernameAndPassword and promptPassword which
use the login storage.
Differential Revision: https://phabricator.services.mozilla.com/D122508
Historically, only session delegates have been allowed in GeckoSessionTestRule
utilities like delegateUntilTestEnd or delegateDuringNextWait.
There's no reason it has to be that way though, and allowing runtime delegates
to use the same utilities removes a lot of boilerplate code that we don't need.
Differential Revision: https://phabricator.services.mozilla.com/D122507
Almost all delegates have getters except for these two. These are also helpful
when implementing delegateUntilTestEnd for runtime delegates.
Differential Revision: https://phabricator.services.mozilla.com/D122505
This change adds a new API that allows Gecko to dismiss a prompt automatically.
This will be used to dismiss prompts when they shouldn't be displayed anymore,
e.g. when using basic auth, we hide the prompt if the server rejects the login
information, as we know that the login info is not correct, so there's no point
in saving it.
We will also dismiss prompts automatically when they become stale, e.g. if a
permission prompt is raised and then the user navigates away.
To be able to dismiss a prompt we need to keep track of existing prompt
instances for a Session. We assign each prompt a unique, randomly generated,
UUID that is used to match the javascript prompt instance with the java
counterpart.
The prompts are stored in PromptHolder. Because the PromptController is owned
by the GeckoSession, whenever the session is GC'd we will also release the
prompts associated to it (if any).
Differential Revision: https://phabricator.services.mozilla.com/D122504
The code in this patch is not needed anymore because now we can handle multiple
in-app runtimes after Bug 1696460.
This reverts commit d49a34c51bc537caffcd559cda07be994105cebb.
Differential Revision: https://phabricator.services.mozilla.com/D123980
This commit allows Android to use the login storage for HTTP auth by migrating
some common toolkit code to promptUsernameAndPassword and promptPassword which
use the login storage.
Differential Revision: https://phabricator.services.mozilla.com/D122508
Historically, only session delegates have been allowed in GeckoSessionTestRule
utilities like delegateUntilTestEnd or delegateDuringNextWait.
There's no reason it has to be that way though, and allowing runtime delegates
to use the same utilities removes a lot of boilerplate code that we don't need.
Differential Revision: https://phabricator.services.mozilla.com/D122507
Almost all delegates have getters except for these two. These are also helpful
when implementing delegateUntilTestEnd for runtime delegates.
Differential Revision: https://phabricator.services.mozilla.com/D122505
This change adds a new API that allows Gecko to dismiss a prompt automatically.
This will be used to dismiss prompts when they shouldn't be displayed anymore,
e.g. when using basic auth, we hide the prompt if the server rejects the login
information, as we know that the login info is not correct, so there's no point
in saving it.
We will also dismiss prompts automatically when they become stale, e.g. if a
permission prompt is raised and then the user navigates away.
To be able to dismiss a prompt we need to keep track of existing prompt
instances for a Session. We assign each prompt a unique, randomly generated,
UUID that is used to match the javascript prompt instance with the java
counterpart.
The prompts are stored in PromptHolder. Because the PromptController is owned
by the GeckoSession, whenever the session is GC'd we will also release the
prompts associated to it (if any).
Differential Revision: https://phabricator.services.mozilla.com/D122504
Depending on glean creates a circular dependency as glean depends on
glean-native which is substituted with GeckoView in omni builds.
Since Gradle 6 capabilities are passed on to consumers using the Gradle Module
Metadata, so now we can just define a glean capability in GeckoView and Fenix
will consume glean-native from GeckoView instead of adding a duplicated
libglean blob (there is code in the glean plugin to make sure this happens).
See also: https://docs.gradle.org/current/userguide/component_capabilities.html
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123572
There's a lot of code that we don't need anymore in our publication path (I'm
assuming it was needed when it was written but then gradle/the android plugin
caught up).
This has the nice side effect of producing better metadata (e.g. our
implementation dependencies end up in the |runtime| dependency group instead of
the default one where they were before, which means the app doesn't inherit our
private dependencies).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123571
This is the last version that doesn't require Java 11, we will upgrade to
Gradle 7 once all components are ready (namely, apilint).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123569
Looks like 6G is not enough for an ASAN build when updating the gradle version.
I tried 8G and 16G on try but that's not enough either.
This also:
* Moves the asan job to `b-linux-large` as the `b-linux` builder does not have
enough memory to run this build.
* Stops running a full build during lints, which is not necessary (and
sometimes uses more memory than the build runner has, failing the lint).
Differential Revision: https://phabricator.services.mozilla.com/D123970
Although we set all selected text to intent that is text processing, it may
cause `RemoteException` since binder cannot handle large data.
So we should truncate the text if it is more than 100K. This value is same as
Blink's limitation (https://crbug.com/1077599).
Differential Revision: https://phabricator.services.mozilla.com/D123410
Depending on glean creates a circular dependency as glean depends on
glean-native which is substituted with GeckoView in omni builds.
Since Gradle 6 capabilities are passed on to consumers using the Gradle Module
Metadata, so now we can just define a glean capability in GeckoView and Fenix
will consume glean-native from GeckoView instead of adding a duplicated
libglean blob (there is code in the glean plugin to make sure this happens).
See also: https://docs.gradle.org/current/userguide/component_capabilities.html
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123572
There's a lot of code that we don't need anymore in our publication path (I'm
assuming it was needed when it was written but then gradle/the android plugin
caught up).
This has the nice side effect of producing better metadata (e.g. our
implementation dependencies end up in the |runtime| dependency group instead of
the default one where they were before, which means the app doesn't inherit our
private dependencies).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123571
Mark Banner
Noemi Erli
Agi Sferro
Tetsuharu Ohzeki
Makoto Kato
owlishDeveloper
Rob Wu
Agi Sferro
Narcis Beleuzu
Botond Ballo
Iulian Moraru
Tomislav Jovanovic
criss
Csoregi Natalia
Marian-Vasile Laza
Cosmin Sabou